That bus error is intentional. When there is no actively determined "draw
window", Palm OS jams an invalid pointer into the variable that normally points
to the draw window. Then, if anything tries to perform an operation on the draw
window before re-establishing what that window is, it gets a bus error.
This approach was taken as it was deemed more sure-fire that attempting to add
asserts all over Palm OS to detect that the draw window was not set and showing
an error message.
I'm not sure where this is documented, but a search of the KnowledgeBase turns
up:
<http://oasis.palm.com/dev/kb/manuals/1719.cfm>
FrmDrawForm
On release 3.5, FrmDrawForm erases the window's rectangle before
it draws, so you must perform custom drawing after the call to
FrmDrawForm, not before. If you have drawn before the call to
FrmDrawForm, your changes are lost. On debug ROMs, the window
handle is invalid until FrmDrawForm is called so that draws
before FrmDrawForm result in a bus error.
-- Keith Rollin
-- Palm OS Emulator engineer
Laurence Lundblade <[EMAIL PROTECTED]> on 09/30/2000 03:39:23 PM
Please respond to "Palm Developer Forum" <[EMAIL PROTECTED]>
Sent by: Laurence Lundblade <[EMAIL PROTECTED]>
To: "Palm Developer Forum" <[EMAIL PROTECTED]>
cc: (Keith Rollin/US/PALM)
Subject: draw before FrmDrawForm in color debug ROM
Seems the PalmOS 3.5 debug ROM along with 3.0a7 emulator has a very
unpleasent error response to an appropriate error check.
When (incorrectly) attempting draw operations like WinSetPattern and
FldDrawField *before* a FrmDrawForm, you get a bus error.
This doesn't seem to happen with any other ROM so maybe it's a debug check
gone wrong?
LL
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
