LiveCode Forums.

Hi there,

A simple question:

I need to display a datagrid with the follow data for each record

number, name, author,section, chapter, thumbnail, unique id

There will be between 20-200 records (these won't change once it is saved as a standalone)
I need to be able to use UTF-8 to display extended latin chars: é, ü and such
My source data is going to be a text file, or can be an CSV file - or can be converted into an .sqlite

What are the pro's and cons here.
Should I just enter the data in the Contents of the of the DataGrid, or learn something else.

ps - Just a newbie looking for best practices!
I have DL'd several lessons of which I'm still getting my head around:
SQLiteSampler.rev
datagrid_databases.rev
Ticket Example Application (tea.zip)

Thanks
Dave

I'm new to Revolution, but I've been testing its performance with data over the last few days, especially vs. SuperCard, which I was using before. And I used HyperCard for years before that. And I can tell you unequivocally that you want to just use a list. 200 simple records isn't *nearly* enough a burden for Rev that you'd need external storage. Keeping everything internal is way, way simpler, and there's no downside.

An easy way to get your data in is to just create a tab-delimited file with a text editor (fields delimited by tabs, records delimited by CR's), and then paste that into a Revolution field. Then you can refer to records by:

put line 5 of field myData into selectedRecord

And you can refer to fields by:

set the itemdelimiter to tab -- once at the beginning of the script
put item 3 of line 5 of myData into selectedField

You can locate a particular record/line with lineOffset. It's very fast.

Good advice, but about the thumbnail--if that's to be displayed as an image, be sure to read up on imageSource if you go with a regular field rather than datagrid.

I tend to agree that external source file or database is not necessary if you are sure that the records won't change. Be aware that fields and other objects do retain their data when the stack is saved, so your standalone can contain the data. (And if records do change, again you can use a file or database, or even save changes in a .rev stack.)

However, there are many ways to achieve a goal, so choose the one that suits your taste!

Even if the records change, I would still store all the data internal to the stack itself, rather than going with an external file. What would be the advantage of having an external file? As I see it, an external file just means more coding, more things that can go wrong, and the necessity of always copying two files rather than one when installing the program or moving it to a new machine. But maybe I'm missing something?

Storing in the stack is handy, partial to it myself in many situations, especially for default data or when I'm making tools for my own use. But when it comes to software distribution, you have to ensure that the stack is located in a folder which is not protected by the operating system, if you want to modify it. So external files can be a big advantage for software that will be distributed. External files are also useful in being separate from the software installation, so that a user can reinstall without wiping out preferences or vice versa. A database can also be an advantage with large amounts of info, or you might have multiple users accessing it. You might even want a file that can be accessed and edited by humans or other software in some situations.

What operating system disallows apps from being modified by default? My OS is Mac, and it's never been a problem since I started with HyperCard in 1987. Is Windows really that cranky?

Mac Classic was, AFAIK, the only OS that allowed that. It was able to do so because of the unique (now deprecated) dual-fork file system in which executable code was stored in the resource fork while data was stored in the data fork. All versions of Windows, Unix, Linux, Irix, BSD, NeXT, and OS X do not allow executables to modify themselves.

This wonderful addition to RevJournal.com from Sarah Reichelt explains this more, with helpful tips on externalizing your data:
http://www.revjournal.com/tutorials/sav ... ution.html

In fact, given that modern Mac systems are multi-user and therefore you can't rely on the user having permissions to write in the Applications folder, it's useful to not only have the data stack external to the app but ideally in any of the user-writable folders, such as Documents, Application Support, or Preferences, depending on the type of data you're storing.

All of those folders can be easily identified with Rev's specialFolderPath function. For a complete list of supported folder constants see:
http://sonsothunder.com/devres/revoluti ... ile010.htm

My experience is that using specialFolderPath("asup") opens the Application Support directory in the root level Library, not the one in the user's home Library. It seems unlikely a user who lacks privileges to write to, for example, the Applications directory, could write to this one. You can use specialFolderPath("cusr") to get to the user's home, where he should be able to write anywhere. You could do specialFolderPath("cusr") & specialFolderPath("asup") & "/myApp'sFolder" if you feel so inclined.

As an aside, I find my home directory is loaded with invisible folders where software is storing configuration and data files, although for the user, who may at some point wish to know or even need to know where these files are, this isn't the most polite solution.

wsamples wrote:My experience is that using specialFolderPath("asup") opens the Application Support directory in the root level Library, not the one in the user's home Library. It seems unlikely a user who lacks privileges to write to, for example, the Applications directory, could write to this one. You can use specialFolderPath("cusr") to get to the user's home, where he should be able to write anywhere. You could do specialFolderPath("cusr") & specialFolderPath("asup") & "/myApp'sFolder" if you feel so inclined.

Good tip. Yes, 'asup' by itself won't get you to a writable folder, but prepending it with 'cusr' will do the trick. Thanks for posting that.