on 9/3/00 8:42 PM, [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote:
> I have a popup dialog form (EditNameDialogForm) which I use
> FrmPopupForm(EditNameDialogForm) in my main form to call. Now,
> EditNameDialogForm can also be called from AddDelNameDialogForm, which
> in turn is called using FrmPopupForm(AddDelNameDialogForm) from my main
> form.
>
> My question is, how can I programmatically find out whether the main
> form or AddDelNameDialogForm is the predecessor of EditNameDialogForm? I
> thought of using a global stack to store the pointers of active forms,
> but I'ld rather not. I'm using FrmValidatePtr() to test which forms are
> active.
Just use FrmReturnToForm(0) to return to the top form beneath a
FrmPopupForm() form. No need to test all your forms for activity, and
FrmValidatePtr() isn't the call you need anyway - you would normally call
FrmGetFormPtr() to test whether a form is loaded with a valid window, but
even that is not needed here.
Now, having said all this, I find that it is much simpler, with less code,
to use FrmDoDialog() for utility forms (EditXXXX, Prefs, About, etc.).
> So, the reference says it is bad to have FrmValidatePtr() in release
> code, why? Now, in the User Interface document of the KB
> (http://oasis.palm.com/dev/kb/manuals/1788.cfm), it says to use it, to
> make code more robust.
In 3 years of Palm developing, I've never used it for anything but debug
code, e.g.
#ifdef DEBUG
(void)FrmValidatePtr(pForm);
#endif
If you look at the source code for FrmValidatePtr(), you'll see all sorts of
sanity checking, but the reality is that if you've loaded your form using
the standard FrmInitForm() call, the only way FrmValidatePtr() should fail
is if you've trashed the heap with a bad pointer and stepped on the form's
data structure. If it does fail, it throws an assertion (i.e. Fatal Error
dialog) anyway, so you can't exit gracefully. My rule is that assertions are
for checking for the unexpected errors in my code, and therefore I don't
leave them in shipping code unless the alternative is something more
horrible (like lost data).
Bottom line: Nothing wrong with calling it in release code, but you
shouldn't have to - it it fails, you have an error you still need to
address.
JB
----------------------------------------------
JB Parrett 603-673-5046
Palm, Inc. [EMAIL PROTECTED]
No amount of genius can overcome a
preoccupation with detail. - Levy's Eighth Law
----------------------------------------------
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
