Hi Ken,

Phil Yates wrote:

> Far be it for me to suggest something that Staz hasn't, but personally, I'd
> build an array (Array$(n,n)) to hold all the data, and whack this in and out
> of the resource fork on startup / closedown (if it changes). If you haven't
> got the code to move the array, let me know.
>
> On one project, I bring in about 10Mb on startup, and it's so fast you don't
> notice it.
>
> Then, you can index the array how you like ...

I think Phil has the right idea, since the data is known and does not change
very often.  I too like to have everything in a single package, vs the Windoze
method of external files all over the place, that may be lost or misplaced.  In
the games, on which I was working for several years, Mac Versions had the two
thousand plus questions and answer-options stored as STR# Resources.  Worked
fine and fast.  When I got around to doing the Windoze Versions of the Games
with Virtual Basic, there were no Resources to be used at the time, so I did
exactly what Phil suggests.  Even with bloated, sluggish VB apps, they loaded
lightening fast.  Some of the Questions pushed the 255 character limit of a
Resource Str, AND the same limitation of an Array Element, so there were MBs of
data being handled.  I don't use Resourcerer, so I'm not sure that it has the
same limitation, but once convenience of having the data in your code rather
than in resources is that it is searchable by FB, in case you DO have to make
changes or fix typos.

IMHOFWIW,

Joe Wilkins

PS  --  If you still want to try the STR# Resources, you can always have a
constant you add/subtract so that item 679 becomes number 1, 680 - number 2,
etc.