From: "Tim Kostka" <[EMAIL PROTECTED]>
> You can generate quite a few of your own events. Pass a value for
> eventsEnum that is reserved for user events:
>
> enum events {
> ...
> firstUserEvent = 0x6000,
> lastUserEvent = 0x7FFF
> } eventsEnum;
>
> Take a look at the EventType structure for the details.
>
While true, it's also important to note that many Palm OS
dialogs such as the alert handler used by FrmCustomAlert,
the popup keyboard, etc will consume custom events and
your event loop will never see them.
This is obvious once you've thought about it, but it means
that custom events are not a good method for passing important
information from one part of an application to another.
They are still useful in many contexts, but need to be treated
with caution. It's not difficult to build your own event
processing system - an array of event structures with push
and pop functions, along with code to test for something in
the array each time you check the Palm OS event queue (or
less frequently if your application suits it) is all that many apps
require.
This has most of the advantages of custom events but you
can gaurantee that Palm OS won't touch your data and can
therefore use these events in situations where custom events
are risky. This also allows you to define an event stack deeper
than the Palm OS one, although I don't know if that's still
as shallow as it used to be.
Chris Tutty
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
