here is a solution.
have your event handler in a seperate file, and declare the
variables globally as static.. no one outsite can reach
them.. so they are based on 'file-scope'.. not
global. :))
if all your form routines are in that file.. they can access
the variable:
ie:
---
mainFormEvent.c
static Byte myByte;
void processEvent(Event e)
{
myByte = ...
}
void otherFunction()
{
myByte = ...
}
---
az.
--
Aaron Ardiri
Lecturer http://www.hig.se/~ardiri/
University-College i G�vle mailto:[EMAIL PROTECTED]
SE 801 76 G�vle SWEDEN
Tel: +46 26 64 87 38 Fax: +46 26 64 87 88
Mob: +46 70 352 8192 A/H: +46 26 10 16 11
On Tue, 4 May 1999, Jason Dawes wrote:
> At 01:36 PM 5/4/99 -0700, you wrote:
> >Hi all,
> >
> >Bare with me I'm new to this event stuff.
> >
> >I can't figure out where to build and initialize my data structures so
> >that they remain available only when a user is in a particular form. I
> >know I could make them *Global* , but as we all know this is not good!
> >:)
> >
>
> Heh, go on, point out the one thing no-one around here mentions ;]
>
> This problem is endemic to the whole "event-driven" world, and it stems
> from the interface not being owned by your application. In the Palm
> paradigm, an application is basically just a glorified collection of
> scripts, and the only thing holding it together is global memory.
>
> There are various thing you can do to reduce the global nature of your
> application, but these are basically "point of reference" methods - you
> could put your info in a Database (yes, just another global, but even worse
> - other applications can get at it). You could have just one global, which
> does reduce the problem but does not eliminate it. You could try and
> subclass the FormType for all your forms, but I suspect that you would be
> asking for trouble. And really useful method of solving your "global"
> problem is to ignore it.
>
> There are a few other more complicated methods of avoiding the problem, but
> they are mostly just that - ways of avoiding it, not solutions. A true
> solution requires that each form holds the data it needs, but it seems Palm
> has not offered any easy way of doing this, such as a "VoidPtr UserData" in
> FormType.
>
> I may not be correct about subclassing - I've never tried, but if you
> wanted to, you could do something like this:
>
> typedef struct MyForm {
> FormType super;
> Blah blah;
> } MyForm, * MyFormPtr;
>
> The only problem is then getting the OS to use it instead of the normal
> FormType.
>
>
>
