We ran into a similar problem when using a non-modal form before a modal form. The problem only manifested itself when our app was launched by an installer, and not when launched by the Launcher.
We got a fatal on OS4.0 devices, and emulated (debug?) ROMs, and above. Never figured out a fix, but a workaround was to do the modal form first... I think in your case, it should be possible to do what you are doing without the WinSetDrawWindow being called with NULL. Many people do this. Perhaps there is something strange going on... Matt ----- Original Message ----- From: "kcorey" <[EMAIL PROTECTED]> To: "Palm Developer Forum" <[EMAIL PROTECTED]> Sent: Wednesday, October 02, 2002 7:43 PM Subject: Re: RE: Ugh...form madness! 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/ -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
