jkc@apple.com (John Kevin Calhoun) (05/15/91)
In article <2746@lee.SEAS.UCLA.EDU> weiss@mott.seas.ucla.edu (Michael Weiss) writes: >OK, here's a request. Would it be possible (either through a HC update or >an XCMD) to send ANY AppleEvent? In other words...let's say that there is >a published list of AppleEvents (which I assume there is, or will be), and >you want to send an AppleEvent to all open applications or to just one >particular application. Would that be possible? HyperCard 2.1 doesn't have a built-in command for sending an arbitrary Apple event, but you can definitely send Apple events from an XCMD. We'll release an example of such an XCMD, called SendAppleEvent, to developers. Technical sidenote: An XCMD can easily convert the address of a program in HyperTalk (a string of the form "Zone:Macintosh:Program") into an Apple event address descriptor, by invoking an Apple event coercion handler that HyperCard installs. More later. Kevin Calhoun jkc@apple.com
imp@tik.vtt.fi (Ilkka Priha) (05/24/91)
The new IAC features in Sys7/HC2.1 are really something and you can do amazing things with them. The "send" and "request" commands work just how Kevin wrote that they should work but it seems to me like the "open" and "close" commands were left to halfway. Because the "send" and "request" commands work only with applications already running in some server you need something else to start them. I understood that the "open <zone>:<macintosh>:<application>" should do the work but it only tries to find <application> from the local machine and shows the normal open file dialog instead of the new network program dialog. I've also tried "open program ..." but that didn't work either. Does anyone have any more documentation about the new features or maybe Kevin could give us some new hints ... -- Ilkka
jkc@Apple.COM (John Kevin Calhoun) (05/26/91)
In article <5654@hemuli.tik.vtt.fi> imp@tik.vtt.fi (Ilkka Priha) writes: >Because the "send" and "request" commands work only with applications >already running in some server you need something else to start them. >I understood that the "open <zone>:<macintosh>:<application>" should >do the work but it only tries to find <application> from the local >machine and shows the normal open file dialog instead of the new >network program dialog. I've also tried "open program ..." but >that didn't work either. There's nothing built into System 7.0 that allows an application to launch applications or to open documents on other Macintoshes. I think that this is a wise omission. Therefore, HyperTalk's "open" command can launch applications only on the same machine as HyperCard. The release notes that I posted point this out. You must install or enable a "remote launching" utility on your Macintosh before other Macintoshes will be able to open documents or launch applications on it. One such utility is HyperCard itself. If HyperCard is running on your Macintosh and you enable program linking, then someone with linking permission can send HyperCard a "do script" event, telling it to launch another application on your Macintosh. For example, if I want to launch Excel on your Macintosh, and HyperCard is running on both my Macintosh and yours, I can use HyperCard on my Macintosh to tell HyperCard on your Macintosh to launch Excel, like so: send "open Excel" to program "Ilkka's Mac:HyperCard" Kevin Calhoun jkc@apple.com
nishri@gpu.utcs.utoronto.ca (Alex Nishri) (06/03/91)
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. I >think that is a wise omission. >Therefore, HyperTalk's, "open" command can launch applications only on >the same machine as HyperCard. The release notes that I posted point >this out. 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. (Applications like HyperCard shouldn't be worried about the security implications of doing this; AppleEvents itself should and does implement security.) Alex Nishri University of Toronto
jkc@Apple.COM (John Kevin Calhoun) (06/04/91)
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
ech@cbnewsk.att.com (ned.horvath) (06/05/91)
From article <53590@apple.Apple.COM>, by jkc@Apple.COM (John Kevin Calhoun): > > The Finder Events were removed from the version of the Apple Event Registry > distributed to developers with 7.0b4... > > 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 Sounds like a good move. This ties into another thread (in another news group) along the same lines. In fact, last summer I posted a note to Apple- Link suggesting that the Finder support events of the kind "please get a selection from the user," to return something like the AppParmHndl every app gets at startup. For Dean, Darin, and whatever other blue meanies still monitor this group: the Finder is the canonical system interface for the user; it provides a "sanitized," high-level, guaranteed-to-work-or-your-money-back interface to every feature the user can see. As such, it can also leverage a LOT of features into EVERY Macintosh app...IF there are AE's to allow all those apps to request services from the Finder. I hate to reinvent the wheel. I love to leverage off other great work. The Finder is a Michelin radial -- I WANT to use it, I DON'T want to reinvent it. The Finder SHOULD be the "hub" application for cooperating AE-aware apps, first among equals. "Make it so." - J-L Picard -- =Ned Horvath= ehorvath@attmail.com