Brandon, I haven't played around with SampleCollapse, but I have encountered some strange behavior with DIA in general. I've managed to get it working for the most part, but I am questioning how/when it actually updates form bounds.
I recently posted a question about a warning I'm receiving saying that the form must be full screen-width. It seems that this message even appears in some of the built-in apps (at least on the T3 and T5 simulators). I know what the message means (and there are plenty of posts on the subject), but I haven't been able to track down why it's happening in my case. It seems like the form bounds are updated before I have a chance to respond to the change in winDisplayChangedEvent. Not that this helps any, but I thought I'd comment on DIA as well... Mark Cameron Techneos Systems -----Original Message----- From: Brandon Roberson [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 08, 2005 12:59 PM To: Palm Developer Forum Subject: Strange behavior with SampleCollapse KB example I'm trying to learn a few things from the SampleCollapse example code in the Knowledge Base. I'm finding the following strange behavior, and I wanted to see if anyone else could duplicate it: * Run the application on the T3 simulator or the actual device * Lower the Dynamic Input Area (the form resizes itself) * Tap in the text field to give it focus * Select "Keyboard" from the Edit menu to bring up the on-screen keyboard (raising the DIA) * Dismiss the keyboard with the Done button. It seems that when the keyboard raises the DIA, the bounds of the underlying form are not changed. When the dialog is dismissed, the code doesn't notice any change, and assumes that there's no need for a redraw. Oddly, the Graffiti2 Help system dialog (right under Keyboard on the menu) doesn't exibit this strange behavior. I suppose it'd be straightforward enough to open the DIA when that menu option is selected, leaving the event unhandled so that the system pops up the keyboard dialog. You'd need to note when this happens, however, and insure that a redraw occurs in the next winDisplayChanged event. An example of this: In Collapse.cpp: static Boolean kbdLaunch; .... static Boolean MainFormDoCommand(UInt16 command) { Boolean handled = false; FormPtr frmP; switch (command) { case MainOptionsAboutStarterApp: MenuEraseStatus(0); // Clear the menu status from the display. frmP = FrmInitForm (AboutForm); FrmDoDialog (frmP); // Display the About Box. FrmDeleteForm (frmP); handled = true; break; /* fix keyboard popup problem */ case EditKeyboard: frmP = FrmGetActiveForm(); CollapseSetState(frmP, collapseStateLockUp); kbdLaunch = true; break; } return handled; } static Boolean MainFormHandleEvent(EventPtr eventP) { .... case winDisplayChangedEvent: //resize and move everything frmP = FrmGetActiveForm(); needToRedraw = MainFormResize(frmP); //Redraw if there was a change in the form //It is important to make sure a redraw is needed because I post //a winDisplayChangedEvent back to the form in response to a winEnterEvent //(see AppEventLoop below). If I simply always redraw it would cause problems //with menus if (needToRedraw || CollapseCheckForPin10NeedToRedraw() || kbdLaunch) { kbdLaunch = false; //On the OS 4 Sony devices you have to erase the form before you redraw it if (CollapseGetAPIVersion() == sonyVersion1) FrmEraseForm(frmP); FrmDrawForm(frmP); } break; .... } This seems rather kludgy, though, and it would provide better encapsulation if this issue were handled in CollapseUtilsSony.cpp instead -- but I don't see an easy way of doing that. Any suggestions? Thanks, Brandon -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/ -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
