Thanks for writing, all.
For anyone else who runs into this, I've figured it out (PalmDebugger is your friend).
What happens in my program:
1) the form is popped up
2) the user interacts with it
3) The user closes the form
4) The closing of the form posts a "window exit event" according to the OS sources.
5) At the top of my main, EvtGetEvent is called.
6) The code (SysEventGet) sees the Window exit event, and calls WinSetDrawWindow(NULL);
On debug roms, this sets the DrawWindow pointer to badDrawWindowValue
(0x8000000)
On regular roms it sets it to the display window, which is why this code
"works" perfectly well on regular ROMs.
7) The next call I was making was 'WinPushDrawState'.
8) The last line in that function (in the sources for OS 4.0) is:
DrawWindow->drawStateP = GState.drawStateP;
Of course, this blows up because 0x8000000 is not a valid location.
The fix?
In my case, I brute force the fix by putting a WinSetDrawWindow(drawWinH)
immediately after EvtGetEvent, and everything's just peachy again. I can test
using the debug roms again.
Whew!
Why does SysGetEvent fuddle with the global Window drawing pointer? That's
not particularly intuitive to me. I call EvtGetEvent to get system events, not
to have side effects happen on the device like having my current drawing window
pointer pulled out from underneath me.
I don't know the reasoning behind the OS operating this way, but if the desired effect
is to stop people calling WinSetDrawWindow(NULL), it would seem to make
sense to me to force a crash when WinSetDrawWindow(NULL) is called, rather than let
the machine crash with a mysterious error referring to 0x8000020, as it inevitably
will with the debug roms.
Also, in future versions of the OS, perhaps SysGetEvent shouldn't be calling
WinSetDrawWindow(NULL) at all, or WinSetDrawWindow should behave differently?
Just my �0.1456 pence.
-Ken
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
