Here's the basic thing - whenever one app needs to communiate with another, it generally sends an appleEvent, which has a four-character class code, and a four character ID. AppleEvents are grouped together into "suites". Applications are required to handle four basic appleEvents (called the "required suite"), consisting of the following events:
aevtoapp - "Open Application" - Sent/triggered when an application is opened. Example: You double-click on a Rev app in the Finder. The Finder launches the app, and then sends it an "aevtoapp" event (which you *could* trap for in the appleEvent handler, but since you get a 'startup' message generated by Rev anyway, this event is pretty useless to trap). aevtquit - "Quit Application" - Sent when the application is being quit. Example: You choose "Quit Application" from the Application menu is OS X, or (I believe) execute a "quit" command in Transcript (you'll have to check on that one, I'm assuming that's the case). If you don't pass the appleEvent, your app won't quit. If you do pass it (or don't trap it), your app will quit. aevtodoc - "Open Document" - Sent/triggered when a document for the application is to be opened. Example: You double click a document for your Rev app on the desktop; the Finder locates the associated application, launches it (sending it an "aevtoapp") and then "tells" the application that there is a document to open (by sending it an "aevtodoc"). You can check the "data" of the appleEvent to get the path to the document you're supposed to open. (More on that in a minute.) aevtpdoc - "Print Document" - Sent when an application is being told to print a document. Example: You select a document on the desktop and choose "Print" from the Finder's File menu. This then does exactly the same as "aevtodoc" (finding the app, launching it and sending it the "aevtoapp" event), but then triggers the "aevtpdoc" event instead of "aevtodoc". You can also query the "data" of the appleEvent to get the path of the document you're supposed to print. Some appleEvents have data that are associated with them, which can be retrieved using the "request appleEvent data" command, which puts any data that the appleEvent has into the local variable "it". Any errors will be returned in "the result" (it'll be empty if there was no error). As you can see by the code you provided in your email, this is the way the document was retrieved. I hope this gives you a foundation on appleEvents; let me know if you need any more info. Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ ----- Original Message ----- From: "sims" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, January 25, 2003 7:17 AM Subject: AppleEvent messages > I've been trying to understand how one uses appleEvents and have played with > the following script. I cannot figure out how one gets the path of the files > from the script. > > One of the things I am trying to achieve is to be able to drop a jpeg > onto a Rev card/window and be able to get the path to that jpeg. > I understand that I can do so with the external that is available > but am hoping to be able to do this through scripting & AE alone. > > Can anyone clue me in? Can I achieve this with Rev 1.1.1? How? > > atb > > sims > > > >Ben Rubinstein [EMAIL PROTECTED] > >Wed Nov 28 07:51:16 2001 > > > >handle the "appleEvent" message. > > > >Put the following handler in your stack script: > > > > on appleEvent eClass, eID, eSender > > if eClass = "odoc" then > > request appleEvent data > > if the result = empty then > > answer "OpenDoc AppleEvent!" & return \ > > & "id =" && eID \ > > & "sender =" && eSender \ > > & "data =" && it > > else > > pass appleEvent > > end if > > else > > pass appleEvent > > end if > > end appleEvent > > > >Build a standalone, and try it. You should see that when you drag and drop > >a file, this handler fires, and the data for the apple event is the path of > >the file(s). > > -- > ----------------------------------------------------------- > http://EZPZapps.com [EMAIL PROTECTED] > Software - Internet Development - Consulting > _______________________________________________ > use-revolution mailing list > [EMAIL PROTECTED] > http://lists.runrev.com/mailman/listinfo/use-revolution > _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
