> > As far as the Frm functions go, if you use them correctly then yes [the > form's initial] FrmDrawForm() saves the bits behind the form, and the > default handler for frmCloseEvent restores the bits or notifies the form > behind it to update itself. > Actually, in testing this, it seems that I am in a catch-22 with respect to the save behind functionality in FrmDrawForm.
For example, say Form A is the active form in the currently running 2-bit app, and my app receives a notification and wants to pop up Form B. If I change depth prior to the FrmDrawForm (using WinScreenMode), even if Form B has save behind checked, after I close Form B, the restoration of Form A fails (I assume because the bits saved are no longer compatible). So, it seems I would have to do FrmDrawForm for Form B to save Form A correctly, then change depth, and then call FrmUpdateForm for Form B to redraw it again at the appropriate depth? However, this would definitely be inefficient, and would probably cause screen flutter or some other undesired result. So, given this scenario, am I forced to skip the Frm functions altogether, and draw the form and form objects with the lower-level Win functions? Or am I missing something? Hopefully this makes sense - any help would be greatly appreciated! Thanks, Geoff -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
