From: "Ben Combee" <[EMAIL PROTECTED]> > At 02:16 PM 8/13/2002 -0400, you wrote: > > fldP = (FieldPtr) GetObjectPtr(m_FormP, fldID); > > If you're doing this in a frmUpdateEvent, your form may not be the active > This led me down another path to a question about frmUpdateEvents and form handlers.
The documentation for FrmDispatchEvent includes: The event is dispatched to the current form's handler unless the form ID is specified in the event data, as, for example, with frmOpenEvent or frmGotoEvent. A form's event handler (FormEventHandlerType) is registered by FrmSetEventHandler. Also the frmUpdateEvent documentation includes: An application can define its own updateCode and then use this event to also trigger behavior in another form, usually when changes made to one form need to be reflected in another form. This implies that an frmUpdateEvent intended for, say, the form partially covered by a popup modal dialog, will have a different formID. Testing reveals that this is true. It also implies that, in this case, FrmDispatchEvent will send that event to the event handler for the background form, rather than the modal dialog. This doesn't happen on 3.5 or 4 (which is what caused the problem that's prompted this). There is a conversation in the archive that suggests that this behaviour is true for FrmUpdateForm calls (which bypass FrmDispatchEvent if my memory serves me true) but not for frmUpdateEvents arising from other PalmOS activity which seem to always be sent to the active form. Can someone in the know confirm or deny this? Also, is the v5 behaviour the same as prior versions (in which it's the documentation which is faulty)? Chris Tutty -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
