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/

Reply via email to