>>I was wondering if anyone >>knows of a publication that more directly addresses making an application >>Apple Event scriptable. > > STAZ sells an Apple Events Filter that works with both FB and PG. Perhaps >looking at that code and accompanying docs may be of help. I believe that the STAZ A&E filter is for sending AEs to other apps. I don't wish to cut revenue for STAZ'n'co, but if budget is tight check first, else buy anyway, i'm sure you'll learn a lot of important stuff. Otherwise, Sending AEs from a FB app was treated in InsideBasic If you have back issues, or the Compleat CD, you'll find valuable info there. Now down to basics, Question: Do you mean making an app AE aware? that is, it reacts to Core AE events Or do you mean a FB app that can be driven by another app, possessing dictionaries etc. And thus would be scriptable from the AE editor, face span, HC or similar? driven - that is you send yourself AEs. If it is the second case then the STAZ filter is just the first step to getting in on AEs, understanding them, and then driving yourself with them. And it could be a long walk. If you look at the way FB grabs AEs, in the examples in the Manual you'll see that you grab the OSEvents that you must treat. But, this is just for the OPEN, QUIT, PRINT etc. events. Once you start to want driving your app, you're going to need to do a help of a lot more. Each user action or app action must be separated into two parts: * the user or app stuff that sets off the action (because this will be able to be replaced by an AE command) * the result of that action - this is your app, and it can do it how it wants. Call these back end, and front end. You are gonna have to then put in sort of switch board that conects these two together, and this is also the place where the AEs will get routed, so that your app won't know the difference between, for example, the user clicking a window closed, and a script that tells your app to close the window. The final stage to scripting will being able to monitor the AEs that your app sends to itself so that these can be captured, played back, or changed in an editor. PG uses a sort of dispatcher device that you could hack, or you can try building your own framework. I did a few posts on this subject a long wjile back, suggesting ways for implementing a 'dispatcher' or switch board that you coud send AEs to, or use to send info from clicks on a tool bar. I *did* have sample code, but things are in such chaos here, that i can't promise to find nor do anything in the coming 3-6 months. The final word of warning is remember that in a scriptable app, everything is scriptable, from moving a window, to importing data, to setting off, or cancelling an operation. So you really need to have clear in your head the verbs, nouns and adjectives of your app. Tell app to close window 3 Tell app to import file "testdata" select word 3 of field "clients" in window "1998 projects" sort of stuff. Hope that this isn't too confused. Perhaps a good place to start would be with some of the commercial scripting editors, a few back issues of MacTech - you can do a search on their site, and some test frameworks that do simple things like opening windows, importing text and pictures. This might give you an idea of the relative difficulty. Message to STAZ'n'Co. AEs and scripting is/are a neat field of the Mac. Perhaps you could expand the AE filter to start covering AE driving for a few simple operations, and probably (and regreattably) just for PG. jonathan -------------------------------------------------------------- ! **** mailto: <jonathan@...> **** ! ! "format utile" studio de graphisme/graphic design studio ! ! 32 bd de Menilmontant, 75020 Paris, France ! ! phone +33 1 43 49 02 04 +++ fax +33 1 43 49 16 51 ! --------------------------------------------------------------