There is a cost associated with calling FtrGet that isn't there when using
real globals, but the question is: is that cost worth it in a given context?
You're basically trading off a possible performance hit for the ability to
make your app not care whether globals are available or not (assuming you
can't eliminate the need for global data entirely).
In the reasonably large app I work on, whose original author used globals
heavily, and which has reasonably tough performance requirements (because it
does things like allow larger-than-the-display images to be drag-scrolled
around), the tradeoff is worth it.
If you combine the pseudo-globals technique with good general design (e.g.,
single-purpose functions that are passed the data they need) you can
minimize the impact of using FtrGet when you do have to use it (typically
inside of event handlers and other system-invoked functions). This also
puts you in a better position to gradually refine your app over time to
eliminate as much reliance on global data as possible.
Mark Peters
in article 39419@palm-dev-forum, Alan Ingleby at [EMAIL PROTECTED]
wrote on 2/13/01 1:46 AM:
>
>>> I don't know what other methods have been mentioned, but you can get the
>>> effect of globals by defining a structure containing all your data,
>>> allocating and initializing it in dynamic RAM, then stashing a pointer
> to it
>>> in a feature. If you do this in response to all launch codes, your app
> can
>>> be written to not care whether globals are available or not.
>> which is exactly what i have mentioned previously..
>
> But won't this method result in slower access to the "globals"?
>
> Alan Ingleby
>
>
>
>
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/