Logan Shaw (that's me; yes, I'm replying to myself) wrote:
> I just got the T5 simulator and tested an app on it, and everything
> seems good except when I call FrmCustomAlert() and the screen is
> in extended-portrait mode (i.e. graffiti area is not visible).
>
> What happens is this: the dialog comes up, and then the graffiti
> area swooshes up to meet it. Then the graffiti area disappears
> again, and the stuff that was behind it (my main form) is redrawn.
> Then the graffiti area swooshes up again, and the process repeats
> until you soft reset.
I think I've worked out what's going on with this and thought I'd share:
(1) I open my form and tell the OS it can be resized
(collapseStateUser, etc.).
(2) The user puts device into portrait mode; my form becomes tall.
(3) I call FrmCustomAlert().
(4) An alert pops up. Even though the screen is nearly 480 pixels
tall, the alert stretches down only to 320, i.e. it is not
flush against the bottom.
(5) The graffiti area swooshes up to meet the bottom of the alert.
(6) My form's event handler gets sent a frmUpdateEvent.
(7) I respond to frmUpdateEvent with (what else?) FrmDrawForm()
followed by some routines that draw some custom stuff on top
of my form.
(8) Apparently, when I call FrmDrawForm(), it causes the graffiti
area to disappear again! (Because my form "wants" to be tall?)
(9) The system then redraws the alert and moves the graffiti area
up again, i.e. effectively it goes back to step 4 above.
The interesting thing about all this is the T5 simulator claims
to be running OS 5.4.5, but if I run the PalmSource OS 5.4 simulator
instead (which claims to be running 5.4.0), the behavior is quite
different: the alert simply appears flush at the bottom of the
screen, even if the screen is taller than 320 pixels. That, and
the alert auto-locks the button that allows resizing. This seems
to work quite well.
So anyway, the solution seems to be to respond to frmUpdateEvent
in a similar manner to how I respond to winDisplayChangedEvent:
I call CollapseResizeForm() (from CollapseUtils) and resize the
form if needed, then redraw (FrmDrawForm() plus other stuff)
regardless of whether I resized.
BUT, doesn't this seem *broken*? Doesn't it seem wrong that the T5
forces me to respond to frmUpdateEvent by resizing the form? Isn't
the purpose of frmUpdateEvent to ask the form to redraw, not to
respond to size changes? If the T5 is going to do this, shouldn't
it at least send a winDisplayChangedEvent first and THEN a
frmUpdateEvent?
- Logan
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/support/forums/
