Here's a few answers:
Inactive forms should only get frmUpdateEvent, frmCloseEvent, and frmSaveEvent.
>What does the the documentation about
>winEnterEvent with the following phrase mean? "This can happen in
>two ways: a call to WinSetActiveWindow is issued, or the user taps
>within the bounds of a window that is visible but inactive."
Say you created a window smaller than the whole screen. If the user taps
outside of the window, then two events are generated. First a winExitEvent
saying which window was exited (and which will be entered). And second a
winEnterEvent occurs saying which window is entered and which was exited. Folks
with Mac simulators or Pose can easily see this in the event trace window.
> daySelectEvent
This is really for the select day object, not for forms in general.
> appStopEvent
Handled by an app's event loop. When seen, the loop normally terminates.
> frmUpdateEvent,
> frmSaveEvent,
> frmCloseEvent
>
>I understand now, that these events can be broadcast to all
>registered event handlers (active and inactive), and that a bug
>in the OS prevents me from using the event.data.frmUpdate.formID
>(resp. event.data.frmClose.formID). Is that correct?
Yes. The bug shouldn't prevent code from working. Remember to only handle
these if your app has special needs.
> frmOpenEvent
>
>Only the active form will receive this as its first event. Even
>before it receives an winEnterEvent?
Do an event trace in the Simulator or Pose and you'll see the following:
Address Book tapping on New:
penDownEvent X:110 Y:152
ctlEnterEvent ID: 1008
ctlSelectEvent ID: 1008 On: 0
frmCloseEvent ID: 1000
winExitEvent Enter: 0 Exit: 32770550
frmLoadEvent ID: 1800
winEnterEvent Enter: 32770550 Exit: 32770550 Enter Form: "Address Edit"
Exit Form: "Address Edit"
frmOpenEvent ID: 1800
penUpEvent X:110 Y:152
This shows the event flow. You hopefully have code similar to below called in
your event loop which sees a frmLoadEvent, loads the form, makes it active, and
sets it's handler function so that everything is set for the frmOpenEvent:
static Boolean ApplicationHandleEvent (EventType * event)
{
UInt16 formId;
FormPtr frm;
if (event->eType == frmLoadEvent)
{
// Load the form resource.
formId = event->data.frmLoad.formID;
frm = FrmInitForm (formId);
FrmSetActiveForm (frm);
// Set the event handler for the form. The handler of the currently
// active form is called by FrmHandleEvent each time is receives an
// event.
switch (formId)
{
case ListView:
FrmSetEventHandler(frm, ListViewHandleEvent);
break;
-Roger Flores
P.S. I will be out next week and probably unable to reply.
Remo <[EMAIL PROTECTED]> on 09/11/99 06:36:47 AM
Please respond to [EMAIL PROTECTED]
Sent by: Remo <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: (Roger Flores/HQ/3Com)
Subject: Re: More Tips and stuff
On Fri, 10 Sep 1999 14:01:35 -0700 (PDT) [EMAIL PROTECTED] wrote:
>> 1. It's only when processing a frmUpdateEvent that FrmGetActiveForm
>> may return another form's pointer?
>
> No. The events frmSaveForm and frmCloseForm can be broadcast directly
> to form event handlers too. You can check this yourself by noticing
> the FrmCloseAllForms and FrmSaveAllForms functions in Form.h.
>
> (...)
>
> So, looking in Form.c, FrmDispatchForm sends events to the active
form,
> called CurrentForm in the source. Other forms will not be sent the
> event. So when a normal event loop is doing it's working, only the
> active form gets events.
>
> But broadcasts to form event handlers are different. They directly
call
> all registered event handling functions.
>
>> I reckon there's a bug in the FrmDispatchEvent code.
>
> Hmmm. I reckon there's a bug too. I see FrmUpdateForm sets formID
but
> that RedrawDisplay, when it broadcasts to forms to redraw, doesn't.
> Thanks.
>
>- -Roger Flores
Let's see, if I got it right:
ctlEnterEvent,
ctlExitEvent,
ctlSelectEvent,
ctlRepeatEvent,
lstEnterEvent,
lstSelectEvent,
lstExitEvent,
popSelectEvent,
fldEnterEvent,
fldHeightChangedEvent,
fldChangedEvent,
tblEnterEvent,
tblSelectEvent,
tblExitEvent,
sclEnterEvent,
sclExitEvent,
sclRepeatEvent
These events deal with form object interaction, and only the event
handler of the active window should get them.
keyDownEvent,
menuEvent,
nilEvent,
winEnterEvent,
winExitEvent,
penDownEvent,
penUpEvent,
penMoveEvent,
frmTitleEnterEvent,
frmTitleSelectEvent
I hope that an inactive form should never get these events. Is this
true? Especially, will the event handler of a visible but inactive
form get pen events? What does the the documentation about
winEnterEvent with the following phrase mean? "This can happen in
two ways: a call to WinSetActiveWindow is issued, or the user taps
within the bounds of a window that is visible but inactive."
daySelectEvent
Does an application get this event at all, or is it locally handled
during the SelectDay call?
appStopEvent
frmLoadEvent
These events should be handled before FrmDispatchEvent is called.
frmUpdateEvent,
frmSaveEvent,
frmCloseEvent
I understand now, that these events can be broadcast to all
registered event handlers (active and inactive), and that a bug
in the OS prevents me from using the event.data.frmUpdate.formID
(resp. event.data.frmClose.formID). Is that correct?
frmGotoEvent
I only get this event, if I send it myself. And only the active
form handler will see it. Correct?
frmOpenEvent
Only the active form will receive this as its first event. Even
before it receives an winEnterEvent?
Remo <[EMAIL PROTECTED]> / / / /
----------------------------------------- -===(o<0=0=0=0=0=0=0=0>===-
Do NOT remove .nospam from email address! \ \ \ \
