On Tuesday, May 7, 2002, at 02:43  PM, MoorePrint@... wrote:

> From a previous discussion it was suggested that we avoid writing to the
> application's resource. In this case how can we have scrolling lists 
> that are
> based on STR# resources?

The answer is simple - Use a temp file or a preference file to save 
these changed resources, and leave the applications resource alone.

How do you do this?

There is a document on this somewhere (I thought it was a technote but 
apparently not maybe the FB site?). Basically you open the preference 
file (or create it if it does not exist) and get it's resource fork 
number, then change gResRef to the resource fork of this file. All 
changes will be saved to this file, but if a resource is not there it 
will be in the app and will get called from there. If something does go 
wrong, all your user has to do is delete the preference file and start 
again.

I've been doing all my apps this way for a few years and it works very 
well (I actually use both preference and temp files files for things 
which are stable across runs and things which are not).

Does anyone have the full reference handy?

Cheers

David

>
> Can we have resources that live only in memory? We can read data from an
> external data file as an index and convert to a resource fro use in a
> scrolling list. In this case I would want to use the PG filter in 
> STR#.INCL
> which uses :
> FN pGreplaceRes(strHndl&,_"STR#",resID,"")
>
> Isn't this writing to the application's resource?
>
> Since I don't really know what I am doing with resources I am all for
> avoiding risky things associated with them. I am currently having a 
> problem
> where occasionally the appication comes on with grbled or missing text 
> in the
> buttons. This text is held in a STR# resource (4000). I am worried when 
> I use
> FN pGreplaceRes to update some of my other STR# I am overwriting that 
> one.
>
> Bruce Moore
>
> --
> To unsubscribe, send ANY message to <futurebasic-
> unsubscribe@...>
>