(This is a resend of a message from Oct 1. I never saw any messages from Oct 1, so I apologize if an answer was sent and has been lost)
>>Subject: draw before FrmDrawForm in color debug ROM >>From: Laurence Lundblade <[EMAIL PROTECTED]> >>Date: Sat, 30 Sep 2000 15:39:23 -0700 (PDT) >>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 >Subject: Re: draw before FrmDrawForm in color debug ROM >From: [EMAIL PROTECTED] >Date: Sat, 30 Sep 2000 16:46:22 -0700 >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. YUK, YUK, YUK! This little trap has just cost me a round of Platinum certification! (and I don't draw to the screen before FrmDrawForm()) Looks like you are throwing the baby out with the bathwater! Can you be specific as to what functions, when called before FrmDrawForm() on v3.5 debug ROMs, will return garbage, but when used on other ROMs would return a valid value. What functions specifically can't we use and what is the valid alternative? We frequently use the technique of 'tuning' up the fields and other UI objects in a form (change fonts, move them, etc) before drawing the form. We are careful not to write to the form before calling FrmDrawForm(). This means that the form is drawn once and the only additional writing is for lines and other special graphic objects. This is a cleaner UI than hiding all the objects you might change, drawing the form and then modifying the objects before explicitly drawing them, one by one. Roger Stringer Marietta Systems, Inc. -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
