>>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!
Looks like you are throwing the baby out with the bathwater!
Now I'm also at fault here. We ran my PDE code through several
million-event gremlin tests on the release v3.5 color ROM, but
never through the v3.5 debug ROM. (OOPS!)
We're not drawing to the window before calling FrmDrawForm
(we know not to do that), but I believe this 'trap' is being triggered
by my code to change the font of a field before the window is
drawn, which uses a field pointer to get access to the field
information. And the field pointer is obtained from a form pointer.
Note: We can't (I believe) use FldSetFont() because that redraws
the field, which would be a no-no.
I believe your ROM change is that either FrmGetActiveForm()
returns an invalid pointer or FrmGetActiveFormID() returns an
invalid value, even when they are used for valid reasons.
But I'm not sure!
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?
================
/***********************************
* Encapsulated funtion to set font id without redrawing the field
*/
FontID M_ChangeFieldFont (FieldPtr fld, FontID newFont) {
FontID oldFont = fld->fontID;
if (oldFont != newFont) fld->fontID = newFont;
return oldFont;
}
/************************************
* Encapsulated function to get field ptr, with cast
* Note: 'validate_object_info()' ensures that the field is in the
* form and (in DEBUG mode) displays an error if it is not!
* One check is to compare FormID to FrmGetActiveFormID()
*/
FieldPtr M_GetFieldPtr (Word FormID, Word FieldID) {
if (!validate_object_info (FormID, FieldID, frmFieldObj))
return NULL; // function to validate parameters
FormPtr frm = FrmGetActiveForm();
return (FieldPtr)FrmGetObjectPtr (frm,
FrmGetObjectIndex (frm, FieldID));
}
//// Extract of code linked to 'frmOpenEvent' event
FormPtr pForm = FrmGetActiveForm();
......
FieldPtr pField = M_GetFieldPtr (ApplNameForm,
ApplNameApplField);
M_ChangeFieldFont (pField, largeBoldFont);
// can't use FldSetFont() 'cos it draws to screen
......
FrmDrawForm( pForm );
....
=====================
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/
