Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!jkc
From: jkc@Apple.COM (John Kevin Calhoun)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: HyperCard 2.1 & Apple events
Message-ID: <53590@apple.Apple.COM>
Date: 3 Jun 91 18:44:35 GMT
References: <53336@apple.Apple.com> <1991Jun3.144816.23495@gpu.utcs.utoronto.ca>
Distribution: comp
Organization: Apple Computer Inc., Cupertino, CA
Lines: 52


In article <1991Jun3.144816.23495@gpu.utcs.utoronto.ca>
nishri@gpu.utcs.utoronto.ca (Alex Nishri) writes:
>In article <53336@apple.Apple.COM> jkc@Apple.COM (John Kevin Calhoun) writes:
>>There's nothing built into System 7.0 that allows an application to
>>launch applications or to open documents on other Macintoshes.
>>Therefore, HyperTalk's, "open" command can launch applications only on
>>the same machine as HyperCard.
>
>According to the registry in the Finder Suite of AppleEvents is an event
>called aeOpenSelection which is used to tell the Finder to open "any kind
>of object which the Finder can open."  Also the Scenarios portion of the
>Finder Suite introduction says, "Users can launch an application on a remote
>machine by sending an Open Selection event to the remote Finder."
>
>Does this work?  If so it sounds like HyperTalk's "open" should use this
>means to launch applications if the target is a remote machine.

Theoretically, it's possible to use Finder Events to open applications on
a remote Macintosh.  However, there are a number of things about Finder
Events which made me shy away from them when I was working on HyperCard 2.1.

The Finder Events were removed from the version of the Apple Event Registry
distributed to developers with 7.0b4.  At the time, developers were told that
the Finder Events that were published in earlier versions of the Registry were
designed before the Apple Events Object Model was adopted internally, and
because Apple thought it best for all applications to communicate using the
same language, namely the Apple Event Object Model, the Finder Events were
"buried" in the b4 release.  However, many developers had been counting on
these events for products they wanted to ship this year, and because of
their complaints, the Finder Events were restored to the Registry.
Nevertheless, the section of the current Registry that defines the Finder
Events is preceded by a long note that, it seems to me, lables them as
"not recommended for general use."

Aside from the topics covered in that note, there are additional design
problems that can be solved only with extraordinary effort on the part of
the client application.  For example, even though it's possible to open the
current selection via the aeOpenSelection event, it's not at all clear to me
how to select the right thing before opening it.  However it's supposed to
be done, it obviously requires a series of events.  But the Finder doesn't
support Apple event transaction IDs, and therefore there's no guarantee that
some other event will arrive somewhere in the middle of the sequence and
throw it off.  Strange behavior may result, and thanks to the Finder's
failure to return meaningful error or status messages, the client will never
know about it!

I decided to wait for a release of the Finder that supports the Object Model
and the Core Event Suite before relying on it for remote transactions.

Kevin Calhoun
jkc@apple.com