WWDC2001 Session 134

Transcript

Kind: captions Language: en okay welcome back the fewer the hearty er the people without lives or families to spend Memorial Day weekend with this is part two of our AppleScript festival this is building AppleScript applications I'm Chris Espinosa the manager of the components and scripting group and we're going to take you through some of the particular issues in implementing your Mac os10 applications some on just porting the application over some on taking advantage of new features and idiosyncrasies of Mac OS 10 it's a real nuts and bolts coding I'm gonna spend a lot of time in project builder going to spend a lot of time in C code it will be cocoa free so I yeah that always gets a mixed response what you'll learn is how to port your scriptable apps to ten which is basically carbonised you know there's really not a lot more than that a couple of special issues what to do about the FS spec problem which you may not have run into yet but as soon as you do it will be tragic how to deal with new Mac OS 10 constructs like sheets I thank Mark Aldred for bringing up both of these to us he was the lone voice crying in the wilderness on the Mac os10 implementers list what about cheats what about FS specs and we were so busy porting it to Mac OS 10 and getting the product out that we didn't really get together and say you know he's right this is a problem until getting ready for this presentation so we've got some fixes and how to debug scriptable applications and and scripts one of the greatest losses that people feel in working on I want to go see what they're doing over there they're having a hell of a time maybe they're giving away t-shirts one of the greatest losses people feel in moving to Mac OS 10 is a development environment is the loss of Mac's bug and all of those great D commands that help you know what's going on in your system well we're going to be showing you how to make up some of that loss in this session so let's jump right into it you've got source code it's in project builder you want to make it scriptable how you do it it's really very simple if we could have demo one up this is our old friend simple text which as you saw in the last session has some scripting capabilities it's got Apple event handlers in it you know and it's got an ability to execute Apple scripts but it's not scriptable per se well we can fix that so if I want to take simple text and make it scriptable it's a simple matter of adding a file and yes we do want to copy it in the new groups folder so we add a terminology file and the terminology file is our AE te as we know it and love it in this case though since this application is a bundled application and it has different variants and what I have to do here is go to the target look at the resources notice that it noticed that terminology dot R doesn't have any variants so I need to go back to the files right there we go and pick localization and platforms and add a localized variant for English okay so now terminology dot R has an English variant that looks like everything else and then I do a build and this is going to do a complete build so it'll take a little while really all you need to do is add a terminology resource an apple script will recognize the application as scriptable if it has an AE T in it cocoa applications have a special info dot P list flag called NS AppleScript enabled which is set to true you can go ahead and set that in your info.plist even if you're not a cocoa application that will speed things up for us we'll recognize you as a scriptable application more readily if that's true but really all you need to do is add a terminology resource so here we go we've built now we should have a simple text executable and if we drag and drop this on script editor script editor shows us the simple tax dictionary and if you launch simple text and tell app let's see if we have a good simple text document here some users [Applause] there we go there we go so scriptable simple text that's all you need to do now when you have a scriptable application you're suddenly faced with the problem of okay now I want to see what's going on and project builder has a very functional debugger where you can look at variables and where you can step through applications step by step but where if you're used to looking at it in project builder where you in code warrior where you could format the variables in different ways as characters or or whatever or in max bug where you could look at it in hex or ASCII as well as decimal you'll find that there are some inherent limitations in project builder and its underlying debug engine gdb that don't have the things you are familiar with and really rely on in debugging Apple events mainly because Apple events are deep complex variable length data structures that involve a lot of things that are 32 bit quantities that are interpreted by us as four characters but aren't actually string or character types and so gdb basically says hey this is an unbounded long opaque data type that has a lot of hex in it so I'm going to show you the hex or maybe the octal if you're lucky this is not very helpful for debugging you want to look at four character codes you want to find out where your Apple event handlers are installed you want to set breakpoints in interesting places you want to look at Apple events in AE desks and you want to do do these all in your gdb environment without resorting to the command line or special tools well here's some help for you first of all write these down and memorize them they're very very handy if you want to look at an OS type all you have to do is cast it if you want to print the value of a variable like the descriptor type of an AE desk if you just print desk dot descriptor type you'll get it in hexadecimal if you want to see what the four character code is you cast it to a char for and that will print it in the characters if you want to set it you can set it in gdb by saying set desktop descriptor type equals but then you have to type the hex or the decimal if you want to set it as four characters you just cast it to a star long star of a string the string will essentially give you a pointer to a temporary and then you cast that to a long star and then you assign that and then that will do the assignment is for by quantity these are two very helpful things to setting and getting descriptor types or OS types in gdb breaking if you want to set breakpoints you can set breakpoints in the Apple Event Manager that will be hit before the Apple event is dispatched to your application this is especially important with the Carbon event model with the Carbon event model you don't usually have a place where you call AE where you call AE process applicant Carbon just dispatches directly to you so if somebody is sending you an apple event and none of your handlers are getting fired how do you know there's no bottleneck in your code to set a breakpoint on well you can set a breakpoint in the Apple Event Manager okay okay now I'm at a EEM dispatcher this is right and at am dispatcher register three is the pointer to my Apple event and if I look at it in hex it's six one six five seven six seven four and then a short hex value which looks like a handle so that looks like an AE desk and that's that's great except it's hex so let's use the trick I used before which is print casting to char for a dereference of dollar r3 and it says it's a EVT yay so I know it's an a EVT okay but let's leave this here for a while go back to the slides because now the problem is okay I want to see what that Apple of it is and how do I know what that Apple event is well I could go in and I could dereference the handle EE and then examine memory from there and poke through it and I might see the the event class and the event code and then the parameters might be in there and if they happen to be an ASCII I could probably figure it out but that's not very helpful and Eva kersky wrote for us a great dekum and in max bug called AV T which will dump it all out but we don't have that in gdb so what we need to do is write in short gdb script and one of the good things about gdb and I know max bug can do this too is that gdb can actually call library functions from a gdb script so what we're gonna do is we're going to call a eprint the AE helpers routine that takes an Apple event and turns it to ASCII and we're going to do some things like calling malloc to allocate temporary memory which we have to deallocate and then we're going to put this all in the script we're going to put it in our home directory and then we're going to invoke it from the command line and this is basically what our script looks like it's got a ePrint desk to handle and then a printf in it and then a couple of dispose statements so we'll go back to the demo machine let's take this and put it in my home directory and then in project builder slide down the debugger this is what the GD BAE desk looks like just like on the screen so let's go back to where my breakpoint is and I'm going to type source till this last gdb a e desk and then just to confirm that it loaded I'm going to type help user-defined okay and it says list of commands AE desk and 8u get Apple event handler those are two very useful things that are defined in that so now I can type a EE desk dollar r3 and it'll chug for a while and it tells me that it's an AE V T it's an OE pp and it's being sent to this PSN and there are no parameters so I'm using the AE print function in AE helpers from a gdb script in order in the at a debugging breakpoint in the Apple event manager to see what my incoming Apple event is this is going to be very very helpful for you in debugging your Apple script applications similarly if you want to know where a event handler is installed if you don't know where your code is there's some code here it calls actually the app actually the actual Apple event routine a you get event handler you pass it to strings for the event class of the event code and it'll tell you the address of the handler and then you can set a breakpoint on that and then you will get a break when that handler files fires this is very handy for figuring out you know when a particular handler handler fires especially if the handler is a wild-card handler okay so with the preliminaries done let's talk about the difficult stuff special topics for coding for Mac OS 10 things you may not have anticipated or known about in making your application scriptable we're going to talk about a minor housekeeping note is a change in the Apple event handler prototype which is going to involve you changing some year code we're going to talk about FS specs we're gonna talk about sheets and we're gonna talk about loading scripting additions into your application okay the Apple event prototype change this is something really unfortunate but we felt we had to do it and the Mac os10 transition was a good time historically Apple event handlers have had a refcon like Windows have ref cons and controls have ref cons Apple event handlers have had ref cons and historically that refcon has been assigned long integer we noticed in putting together the headers for Mac OS 10 that all of the other ref cons in the system were unsigned long integers all the others all the other ref cons are signed historically the Apple event handlers had been unsigned we decided to fix this and fixing this means that you're going to have to change the prototypes on your Apple event handlers and the and the headers on the handlers and the but not the installation code it's otherwise you would have to do a lot of casts it's not pleasant but it's just something you have to do it's it's just some housekeeping but I just wanted to let you know that that's coming up more serious is the issue of FS specs F aspects have been pretty much the hard coin of talking to the file system since people really started using the the new file system calls in in Mac OS 8 FS specs have been fairly useful they let you get at things in the file system without having to deal with paths but there are some problems in Mac OS 10 FS specs first of all are limited there their path name is HR 255 and it's intended to be in the system encoding and that means that an ephah spec can't really refer to a long file name or refer to a Unicode file name very well we're strongly recommending you you work with FS refs that can do this but FS specs have a fundamental limitation but there's a problem if s refs can't refer to non-existent files and FS specs can and the reason why a lot of people like FFX is that you can use them in creating a new file and that's important in Apple event Apple scripting application where one where a script may want to tell a application to create a new file you want to some compact useful way of saying what new file to create and an FS spec can't do it because it can't use long Unicode file names and then an FS ref can't do it because it can't refer to non-existent files what complicates this is that in the carbon model each carbon application has its own view of the vcbq that means each carbon application has its own list of volumes that may be in a different order so a volume ref num is not valid across processes that means that an FS spec in an ffs ref which our volume ref numbers are not valid across processes so you can't really legally send an FS back or an FS raft from a script to an application because it's volume list may be different and it may be talking about a different volume we we get these bugs every once in a while I wrote this script and I told this application to save the file but it's saving it on a different disk why is that well it's saving it on disk negative - and in that application disk negative 2 is a different disk than in that one if you're lucky it works if you're not lucky and you're going deep down you probably don't have the same directory structure on each disk that the derp IDs are probably not the same and it just plain doesn't work so we need a solution to this if you want to send a save event to your app if your application wants to process a save event you need a way of getting the file name that's not FS ref or FS spec based well the answer is you know whenever you can you use type alias if we're open or for print events or for anything else dealing with a file type aliases are valid across processes and they can represent long Unicode file names but they too cannot represent non-existent files so for non-existent files we are creating a new type called a type file URL and the date of a type file URL is the same format as the eff URL drag flavor if the finder drags a file to you using the drag manager and drops it on you when you get it out you probably coerce it to an FS pecker in FS ref and then you get it in your context but inter-process it's being sent as this F URL data type and this F URL data type is process independent it can refer to non-existent files and it doesn't rely on volume ref nums so it's legal to send across processes we're going to use the same data format with the same four character code to specify new files in Apple script what's nice about it is that it is filesystem independent it encodes special characters so you can have a file name with colons or slashes and you don't have to parse them out it can distinguish between files on volumes that have the same name which is really important and it's valid across processes and boxes and since it's a URL it's even valid across machines really we're gonna provide you with some sample code george warner and john Montreat Briand are working on this now we're providing a few routines to basically create and extract file URL data types from things that you see every day from nav services replies from IE desks to get them in and out of Apple events and also to create a new file given an F URL in one step rather than having to take it apart and find the file name portion the directory name portion and call the FS create Unicode call so we're just packaging this up as a bunch of sample code we're also providing coercion x' between this F URL and all of the interesting types all of the interesting character types type chart type style text type Unicode text so that users could see these if they wanted and they can create them and all the type files the the C file object specifier the type F SS and type FS ref a aliases and the object specifier of course so that people can actually compile these in Apple script so how you use these is very straightforward say that you are an application that is factored and you send yourself a save event so after somebody chooses save and they fill out the nav reply record you want to generate a save event with the file name that's been picked in the nav reply record and send it to yourself to actually save the file well the nav reply record gives you a directory URL and a CF string of the unicode file name those aren't very useful to you when you want to get them into an AE desk so we've created one call that takes that nav reply and makes it into a CFL the underlying core foundation URL datatype and then another call that puts that CF Earle into an apple event as an F URL parameter and all you have to provide is the key so in basically three lines of code you can take your nav services reply and stuff the fully transportable file name from that into an outgoing apple event similarly on your save file apple event handler you're going to get an in parameter in and it can be anything it can be an alias it can be an FS spec it can be an FS ref it can be a type file Earl but you want to you basically want to know two things one does is does it already exist and if it doesn't already exist how can I make a file that does exist so I can write into it and get an FS ref from it and so basically what you do is you get the the in parameter as you try getting it as an FS ref if that fails then either there wasn't something there or there was something there that couldn't be resolved to a file that exists so you guess okay if my FS if my FS ref succeeded I'm writing to an existing file if it failed I probably want to create a new file so then you try to get the in parameter as an Earl and if that succeeds then you know hey I've got this reference to a non-existent file and we you call one of these other sample code routines URL create with CF URL you pass it that Earl and you get back an FS ref of the brand-new created file and then you can proceed as as normal so what we've worked to do is provide sample code that not only demonstrates how we do it but is very easy to use in the common application which is create an apple a send Apple event to send to yourself and receive a send Apple event and process it so now I'll show you how that actually works once again in simple text the first thing I want to do is add and include for my dot H file and add that dot H file and that's going to be this here's my file early Sh so it didn't copy it so it didn't add it so let's not copy it okay so here's my dot H file and basically it defines a create from nav apply create desk from SIA URL put for am and put key CF URL create one from a desk create it from an Apple event parameter create it from a record key created from an FS spec create a new file with an Earl and then a couple of coercion handlers and one of the things we want to do is we don't want to install those coercion handlers so let's get the source okay now I want to add a save event handler and we're going to call a save event handler and see how this does it so I'll go open up my add-ins and I've got a save apple event handler julia child format already canned and I'll go to where I should add my save event and paste it in and I'll go back and install my save event handler this is the code to do that and then install a couple of coercion handlers so that I can process a few RL types coming in I'll copy those and I will add them right in here okay and then I will build while that's building what I'll do is go to my home library scripting editions folder and I'm going to copy in a special version of standard editions which has a version of choose file name which has been updated to return F URL and we'll see this in the event log and we'll quit the script editor just for fun and we'll put simple text just to make sure and our build has succeeded so now we'll run and we'll open up this save as example and so this is fairly simple this is what you might see in any script set f2 choose file name save document 1 in F ok but normally choose file name would return you a file specification and you'd send it to save but now we're sending it a F URL and the F URL will result in a new file so we'll turn on the event log so we can see exactly what's happening run it choose file name ok so notice that it said save document 1 in file URL file : / / localhost / user / SBC h / document / baz text ok so instead of an FS spec it came across as a URL notice that simple text saved it as vas text and when we go back to the finder and go look in my home directory in My Documents folder there it is so this is an example of how you can very simply without really changing your your application architecture just use a different data type in this case this the the F URL data type to get around the problem that FS refs and FS specs can't be sent in Apple events as I said we're working on the sample code for this it's going to be released as a tech note and you'll have access to this to incorporate into your applications the coercion handlers that I talked about we will incorporate into a future version if you want to ship something now for Mac OS 10 point 0.3 you can install the coercion handlers yourself in the later version of the operating system when they're already installed you can either continue to install them or just stop installing them and you'll inherit the ones from the system so what this means to you is that with this sample code it's safe and probably important to remove all type FS specs from your scripting interface if you're doing Oh Sachs's oh s--- accent if you're doing factored applications if you're doing send to self applications you should probably not send yourself FS pecs you should probably not expect to get FS pecs or FS refs from other applications you should really migrate to this new data type it's the same one that we use in the drag manager its URL base there's support for it in core foundation we're providing sample code for you to do it it's something you should really look at migrating to the second issue in Mac OS 10 is handling sheets sheets are window modal dialog boxes and as window modal dialog boxes they behave differently than dialog boxes do on Mac OS 9 Mac OS 9 dialog boxes are application modal they block the whole application so that when a script tells you to put up to do something and you put up a dialog box that script halts because you won't send back a reply apple of end until that dialog box is dismissed in many cases this is what users what scripters want because it mimics the user experience the problem is with a window modal dialog box your application doesn't help what happens is that you get an Carbon event in and you show the sheet and then your Carbon event handler exits and then your application is just running and the sheet is going to be called by a callback a sheet of n handler and then you install a procedure on that to actually do what the sheet does whenever it's dismissed so you basically have these two threads of execution one is the the main event handler and one is whatever happens when your sheet event handler gets called well if you mimic that with an apple event handler what's going to happen is that the Apple event will come in it will pull down the sheet and it will return without an answer because the user hasn't filled out and okayed the sheet yet ok if this is like a save dialog box the you won't know whether it actually got saved if it's a if it's a sheet that says this document has not been saved you are you sure you want to and the user presses cancel you know maybe you want to return a user cancelled error from that rather than just say oh it's okay because basically your script will continue executing and it will continue executing on the assumption that the previous event has been fully handled when in fact it hasn't it's still waiting there for user input bad things can happen so there are there are four solutions to this the first one is the easiest way and it's probably the best way is to always provide a way from your scripting interface to let the script er avoid pulling down the sheet that's going to be the safest if the script err can provide all the information that's supposed to be in the sheet in the in the event and you can avoid pulling down the sheet altogether and just process the event do that it's the best safest way but what if there are cases where you have to pull down the sheet or if the scripture actually wants you to pull down the sheet and have user intervention such as the shut down the entire system event you don't want to prevent the user from having the opportunity of saving open documents in that those sheets really have to execute and you don't want the shut down the system event to say okay I'm done and shut down the system while all these sheets are pulled down waiting for users to save files it's not the right thing to do so the wrong way is to just return even with the sheets are still down your script and your application will get out of sync your script will continue executing it'll keep firing events with the assumption that say that window has already been closed or that document has already been saved or it may go look for that document in the file system now even though it hasn't been saved yet and it won't find it and it'll be an error you don't want to do that the cheap way is to see if you're pulling down the sheet based on a user action or from an Apple event and if it's being pulled down from a user action make it a sheet and if it's not make it application modal and if you make it application modal it'll behave like mac os9 it'll block the application that's a cheap way to do it it's effective it's really easy to do with sheets it's fairly easy to do with nav Navy I logs there's just actually one bit you set a nav dialogue to say make this app modal rather than making it window modal and it does the rest for you it it'll work doesn't provide the best user experience the nice way and the way that works if you really want your scripts to be able to pull down sheets and wait for user input before resuming is you have to suspend the incoming Apple event and then resume it when the sheet is dismissed and let me let me show you how that works so somebody sends a close Apple event to your application you create the sheet you install the sheet event handler you show the sheet and then you suspend the incoming event and when you return from the Apple event handler you don't return all the way it doesn't fill out a reply and send it back to the original application it leaves that application hanging fire until the reply is actually filled in this is the behavior you want because if this is coming in from an external script that external script will just think gee it's taking a long time to process this event and maybe it'll timeout if it's got a long time out it'll wait the right thing happens then your sheet event handler when somebody actually does click a button you hide the sheet you dispose the sheet you get the information about what they actually did you maybe put that in the reply and then you resume the Apple event and at that point the reply Apple event is actually delivered to the caller and then the script says oh this is what happens and then execution proceeds and then in your process then you can hide the window and dispose the window and do everything you want and then your sheet handler proceeds well you want a special case that because you don't want to hang yourself while waiting for a sheet application to occur so basically in your window event handler if somebody clicks the closed box or chooses clothes you can create a Apple event and send it and then your Apple event handler has to notice hey this is sent to self not sent from somebody else there's nobody waiting on me I'm just going to execute and return I'm not going to suspend the event and this is the crucial part if the events coming from outside you suspend it if it's a send to self event you don't and then similarly in your sheet event handler if there's a suspended event you resume it and if there's not you don't makes kind of sense because if you try to resume and there is no suspended event well it doesn't quite work so going back to sample code I have here I took the sheets sample code from DTS and hacked it up fairly majorly to make it scriptable editing a bunch of events but you can see that I've added Apple event handlers for you know open and reopen and open doc and I've added a Apple event handler for make a new window and this creates a new window and then in the and I've also added an Apple event handler for cloak to close the window okay and in the carbon event handler here is the carbon event handler for closed basically what I do is I use the very convenient AE helpers to build an apple event and I build an apple event that says closed saving ask and I send it to myself and so when I click the closed box or when I choose closed from the menu I'm going to generate an apple event which is good for recording purposes and then I'm going to catch it in my closed Apple event handler okay well let's look at what happens I have a switch in here and right now I'm going to handle it just by returning and I believe that this is already built great so if I run this application it comes up and nothing happens and let me open this little script and what this script does is it makes two windows closes one saving ask and then uses a speech generator and I hope the sounds working to say I'm done with the script if sound isn't working just watch the stop button so we run the script I'm done with this cream now it's done with the script but the closed operation hasn't finished okay and in fact the applications still live and I could cancel this or I could close a different window but the script is already preceded on the basis of the understanding that the first window was already closed okay this is this is not the behavior that we want so let's quit that and let's go back to our switch here and say handle by suspending okay and let's put a breakpoint at suspend the current event and a breakpoint okay so now we only have one scriptable sheets great and it's bouncing and it's running so we run and we hit our suspend breakpoint okay now let's and our script hasn't terminated yet so we go back to scriptable sheets we click okay we hit the resume breakpoint I'm done with this cream and then we're done with the script so this will be releasing a sample code too it's fairly straightforward there are a couple of complications though if we could go back to the slide the one thing I talked about before is you don't resume the send to self events that it just doesn't work don't do it the second interesting thing is if you have a coding style where you if there's an Apple event error you propagate that through up to upper levels it's really interesting in your Carbon event handler if your Carbon event handler sends Apple events and the Apple events receive errors don't propagate those errors back out of your Carbon event handler because what will happen is that carbon will dispatch that back up the carbon calling chain so you need to be intelligent about the relationship between your Apple event handlers and your Carbon event handlers and understand that if an apple event because the when you suspend an apple event it actually returns a timeout error to the caller so if you're sending well you need to work out the relationship between your Carbon events and Apple events and not send things back up the chain because carbon will reduce patch it and then you will get several invitations of the same event which is not what you want in this case you get two sheets on one window which is not good if you're an attachable application there are a couple of things to make sure of you want attached scripts to behave like external ones in that you want the scripts to pause but when you're executing the script the events are being sent sent to self so your simple case of if it's coming from outside it's a script I suspend if it's coming from inside its a factored command I just executed that doesn't work but you can't suspend it because it's sent to self so what do you do well in the case of if you're executing a script that is sending yourself commands what you need to do is execute that script on a thread and have a send function for that script execution for that call to OSA executors or execute event that blocks that thread until the event returns and that's essentially the way to suspend and resume that of end execution under your control rather than the Apple event manager control and then you unblock the thread in your sheet handler that there not a lot of attachable applications that are going to be scripting Saveur things with sheets if you happen to be in that case and mark wanted to know about this because he is this is how we think you should do it so what this means to do to you if you adopt window modal dialogues if you adopt sheets or the sheet style nav dialogues you have to change the way you deal with event handlers you pretty much have to go to the Carbon event model it really helps to go to the Carbon event model and you need to plan the relationship between your Carbon event handlers and your Apple event equivalents let me do one quick thing about scripting additions in Mac os10 from the programmers point of view I talked about from the users point of view of where you put them and how you invoke them from the programmers point of view you don't get scripting additions in your application unless you make an OSA call in which case you do but what if you wanted to get scripting additions and execute them in your context and you don't want to have to go over the over go through the overhead of starting up Apple script in order to do it we have some following magic stuff read quickly basically you grope our library for a special symbol called OS a install standard handlers if it's there you call it and then you send yourself a special event called the GD ut event this is the event that Apple script sends to load scripting additions and when you send this to yourself then it'll load all the scripting additions into your titian you only need to do this if you really want scripting additions to execute inside your application space inside your application process and you don't and you're not going to execute an Apple script yourself it's a fairly rare case we generally don't recommend groping our frameworks to find private symbols but this is a fairly safe one you're only calling it if it's there and in the future if we if we do this differently we'll remove that symbol and then your test will fail you won't do anything everything will just work fine in the future they may be loaded into every application by default we're still looking at that there are some security implications to that we definitely don't want people sending for example terminal or login window events that get executed by secret scripting additions that they put in the network scripting additions folder and all of a sudden they get root privileges and can write all over your machine we need to look at that model before we execute scripting additions in every applications there are alternatives and one of the alternatives is great third-party product called script debugger and Mark Aldrich is going to come up and show you how you can use scripted debugger to debug scripts executing inside your application mark so I'll start by showing you a few features of script debugger as a just an apple script debugger so you can see how your script might execute what I have here is a little FileMaker database with with a picture and some text and a script that that works with it excuse me so what this script does is essentially read some data out of this FileMaker database and do some stuff with it script debugger gives you all the standard debugging things you need breakpoints and other sorts of things so let's just do some execution as you go variables come into the browser you can hover over a variable and examine its value you can run to a breakpoint script debugger shows you the scope of all you of your variables as you go anything that has a white background if global anything that has a yellow background is local to this function or handler in Apple script terms and anything with a blue background is built-in to Apple script itself one of the things you can do is if you don't like the way the browser operates or you want to see something you know in a larger view you can open us a separate window and you can view it in a print form as the source code from Apple script or in best and one of the cool things about best is that it allows you to deal with things other than textual data so for example as this script reads pictures and text the debugger shows you the actual live data [Applause] now if you're trying to debug a script running within your own application you need to be a scruffy bugger gives you the ability to actually invoke that debugger from your context not just the script debugger application and the user interface for this is is simply switching OS a languages so you switch from Apple script to Apple script debugger and save your script in this instance it's an applet and then when I drop a few files on there the applet launches as it normally would and then script debugger comes forward and you can actually see exactly what your applet received from the finder which in this case is a pair of aliases and bear with me it's still beta you can step along examine all the things that are going on the key element here is that if you if you support what's known as the generic OSA component in your application if you have a script menu or any other setting in which you X set a setting in which you would execute a script apples the OS the generic component will automatically load the appropriate language and by doing so you let the author of the script [Applause] you let the author of the script make the choice and in this instance they've chosen the debugger but they might choose the OS v the UNIX shell OS a component that Kris was demonstrating earlier on and so with that simple switch of a language the debugger can be executed inside your application and you can see exactly what you're doing and as sort of the final example of how cool that might be [Applause] so there you can have the debugging running inside the show thank you very much great thanks mark so Mark's done a lot of work over a period of years trying to work around if we could have the slides back the fact that Apple script doesn't have any system level debug api's and we're trying to rectify that and work with him and the developers of other debugging applications if we could have the slides back to actually put in some debugging api's into apple script so that they could take advantage of them and you could take advantage of them in your applications or invoke them from gdb for example to find out what's actually going on inside your application when you're executing scripts we have a framework for what the API is look like the basic contact concept is that there's a debug session which is based on OSA IDs and there are stack frames and you can walk the stack the stack chain and look at Global's locals and properties of a handler or a script in this stack frame that looks like it'll have a good match with the user interface of the current debuggers and also all the things that you may want to do from inside the script also providing an interface to break and single step and step in to step over continue all the things you'd expect from a debugger the important thing is that it needs a remote mode as well and that remote mode will of course be via Apple events so that you could send them from your debugger you could send an apple event to any executing application executing a script to halt that script application and then have the entire debugging transaction over Apple events this would be very exciting when we've got Apple events over the Y over the internet again because you could do remote debugging over the internet between two machines on Apple script we're really looking forward to that and we're working closely with the developers of debugging applications so to summarize everything you need to make a good scriptable application both an application that implements script ability and an application that executes sappal scripts is in carbon framework now and there should be nothing holding you back from developing great scriptable applications if there is let us know it's easy to invoke scripts from your code I mean simple text does it in the demo it's three or four lines of code and if you do make sure that your OS a component agnostic so you can take advantage of things like the OS a script the shell scripting component or the or mark Aldrich the debugging component so that if you execute scripts you don't just execute Apple scripts but you execute any scripts because we'll be widening the the range of scripts in the future make sure you migrate away from FS specs because FX specs are not the right way to send things between applications please adopt the sheet user interface in aqua and take the ways we've shown you to make sheets work in scripts and use the development tools project builder is a very effective development tool for developing testing debugging and deploying your application there's only one more thing left to do and that's the feedback forum which is going to be across the hall because we have sixteen fifteen fourteen seconds left we're not going to take any QA here but we'll take any in the feedback forum once again Jason is the technology manager contact him I'm the engineering manager used lists George Warner's our fine tech support you