Roger,
> The change you're proposing is to make FrmUpdateEvent directly call and
> update inactive forms. This could be done, but it has some problems,
> like the form is generally obscured, so drawing doesn't help because the
> draws would be clipped away. Also, when the form covering is erased, it
> will restore pixels to the way it used to look.
Understood.
> The Palm OS convention is to have FrmUpdateEvent place the frmUpdateEvent
> on the queue. This is carefully done so that when EvtGetEvent returns it,
> frmUpdateEvent's form is the active form, which has full access to draw to
> the screen.
Only if you specifically insert a call that results in a change to make this
the active form prior to the FrmUpdateForm. Wouldn't it be more logical to
hold a frmUpdateForm event pending until the specified form becomes active,
merging (ORing) the update codes for multiple FrmUpdateForm calls?
> So if the Reference claims that FrmDispatchEvent sends events to inactive
> forms, that's wrong. It only sends them to the active form. That's a
> general model that Palm OS follows. Exceptions are the three cases of
> broadcasts discussed.
So what's to stop broadcasts of frmUpdateForms having the same problems with
clipping and restored bits behind overlapped windows?
I guess I just don't understand why FrmUpdateForm has this formID parameter
at all!
Stephen Best
Bitware Australia Pty. Ltd.
