Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!olivea!apple!well!wdh
From: wdh@well.sf.ca.us (Bill Hofmann)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Application defined events in Multifinder
Message-ID: <23442@well.sf.ca.us>
Date: 4 Mar 91 03:03:23 GMT
References: <1991Feb23.140420.20707@ux1.cso.uiuc.edu> <25921@neptune.inf.ethz.ch>
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 26

In article <25921@neptune.inf.ethz.ch> mneerach@iiic.ethz.ch writes:
>In article <1991Feb23.140420.20707@ux1.cso.uiuc.edu>, resnick@cogsci.uiuc.edu (Pete Resnick) writes:
>>I can't seem to find any documentation on this one. It appears that
>>PostEvent can be called at interrupt, so that I can post app1Evt's
>>from asynchronous completetion routines in my program to signal that
>>events have occurred. It is not clear, however, how I am to distinguish
>>my app1Evt's from those that might be posted by another application
>>running under Multifinder, or whether I will see these events at all
>>if I have been suspended. Is this documented somewhere, or does anyone
>>know what the story is?
>
>I don't know, but I believe Apple is discouraging developers from using
>appXEvt's for the purpose you described, since under extreme circumstances,
>events may be discarded. Maybe it's better to just set a boolean flag which
>is checked in the main event loop.

Yup, Apple now recommends that you do not post events within an application.  
The problem is, there is only 1 event queue.  If you post an event, there's
*no* guarantee that you'll get it.  If you want to build a message-driven
environment, pre-System 7, you need to build your own message queue.  That way,
you have control (note the other problem, as mentioned, is that since there are
only 20 events queued, it's pretty easy to swamp the event queue if you're
generating events programmatically.  This is why Apple rewrote the AppleTalk
manager to stop using networkEvts.)

-Bill Hofmann