🚀 go-pugleaf

>We're having some difficulty implementing Apple Event support in MCL 2.0p1.  

Tod,
   There is some confusion as to what events are expected when an
application starts up.  If the application is started because the
application icon was double-clicked in Finder, an Open Application event is
received.  If the app is started because one of its documents is double
clicked, NO Open Application is received...an Open Document is received
instead.  (Or a Print Document if a document is selected in Finder and the
Print command is chosen.).
   So...when an application starts up and observes that Apple events are
implemented, it should do whatever it does to initialize REGARDLESS of why
it is starting, then await one of the events.  On Open App do the "I was
double-clicked" stuff (untitled document, or whatever)...on Open Doc do
that stuff.
   None of the events will be received if the right bit isn't set in the
SIZE resource (but if that were the problem you wouldn't get the Quit
Application event either, and that shouldn't be the MCL problem you're
seeing).

   On the CD ROM, look in folder Dev.CD Nov/Dec 92:Tools &
Apps:OS/Toolbox:Apple Events:AETracker 3.0: for a nice little Control Panel
which patches the trap which all Apple event traps go through, and will
report some or lots of information about some or all of the calls (easy to
select what).  It should answer many of your questions about what events
are being passed around.  $5 shareware from one of the Apple DTS guys.

   Also on the CD ROM, in Dev.CD Nov/Dec 92:Tools & Apps:OS/Toolbox:Apple
Events:AE & Scripting Dev Kit:AE Tools:FKEYs: there is a nice FKey which
displays a list of the currently installed Apple event handlers.  Useful
sometimes if you "know" you're set up to receive an event which isn't
coming in.  Also useful to make sure that any System handlers are being
removed when an application shuts down (I've found two guilty apps so far).

   None of what I've said above is directly related to MCL.  I see that MCL
installs one wildcard handler which receives all incoming events (that's
the little FKey at work).  I haven't looked at what that handler does.
------------
   After running the AETracker against MCL 2.0p1, I have a concern:
------------
AETracker record
Brought to you by C.K. Haun <TR> and RavenWare Software
Tracking initiated in application:Finder 

MCL 2.0p1 at TickCount: $0000298D
AEInstallEventHandler
Class:  aevt ID: **** RefCon  $010DE76C System Type

MCL 2.0p1 at TickCount: $00002990
AEProcessAppleEvent
Class:  aevt ID: oapp

MCL 2.0p1 at TickCount: $00002990
AEGetAttributePtr
Wanting: Descriptor Type:**** Key Type :  evid

MCL 2.0p1 at TickCount: $00002991
AEGetAttributePtr
Wanting: Descriptor Type:**** Key Type :  miss
Routine returned an error : $F95B errAEDescNotFound

MCL 2.0p1 at TickCount: $00002991
AERemoveEventHandler
Class:  aevt ID: ****

MCL 2.0p1 at TickCount: $00002ACF
AEInstallEventHandler
Class:  **** ID: **** RefCon  $00000000 System Type
-------------------
This is the result of double clicking MCL itself.  Note that MCL seems to
be installing a bogus handler (which seems to work) to catch event class
<<nothing>> (probably 0x00000000), ID **** (typeWildCard).  (Or, there
could be a problem in AETracker, but I've never before seen it mis-report
an event Class.)  The Open Application arrives and is processed, the bogus
handler is removed and a new, valid handler for **** **** is installed.

I haven't looked at the underlying code, but I suspect the root of your
problem is in this use of a different handler at startup.
   --John

--------------
John W. Baxter   jwbaxter@halcyon.com   [BAXTER.JOHN on AppleLink, from
AppleLink only.]