> > 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).
You seem to have left out using WinScreenMode to restore the screen mode. The form beneath you may have initialized various data members on the assumption that the screen mode isn't going to change mysteriously. So even if it's technically possible to skip that step, you may cause problems for the other app if you don't restore the screen mode. And if both forms are in your app, then there is no problem since you can use some other mechanism to force form A to redraw itself. Form A does correctly handle the frmUpdateEvent and redraw itself in its entirety, right? -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
