When writing scripts and interfaces with multiple buttons per window. Is there one onclicked event within which you then have to identify the button “theObject” press by applescript name or should, as in VB etc, there be an onclicked event handler created for each button linked internally via “theobject”.
on clicked is called whenever an applicable UI element is clicked. If you have linked the on click call to a script with an on clicked handler in IB, the UI element will call that script when it is clicked. If you have multiple UI elements calling the same script when clicked, you need to identify which item you’re dealing with (by way of its AppleScript name assigned in IB, eg. set objectName to name of theObject / if objectName = “buttonName” then…) and act appropriately.
You can create a different AppleScript text file to deal with each separate UI element. I vaguely remember back at the beginning of ASStudio some caveat from Apple about doing it this way - something about compile and launch time - I don’t know if this still applies. Depending on the size and complexity of your application, it probably won’t matter too much.
Some stock UI elements will behave normally without any scripts to deal with them, eg. a switch button will change states when clicked regardless of whether you have any script handling the action.
Thanks for taking the time to reply. I understand what your saying but I find it strange that Apple the kings of event driven OS principles would produce a system where you have to deal with all possible buttons within the one handler (multiple if statements!) or produce a separate script to handle each onclicked button event.
I dont know why I got a bee in my bonnet about this now, maybe moving to Xcode2 and looking for changes, because when I look back at old scripts I find I have adopted the script per button solution. Maybe I read the Apple guideline that you referred to!
Anyway if thats how it is you just got to live with it.
Once angain thanks for the time and effort you made on my behalf.
VB keeps things seperated, it’s just presented differently.
On a different note, take a look at this script. It handles six different color wells.
on clicked theObject
try
call method "getHEXValue:" of class "methods" with parameter theObject
tell user defaults to set content of default entry (theObject's name) to result
on error errorMsg number errorNum
log "Error (" & errorNum & "): " & errorMsg
end try
end clicked
Why should I duplicate that code six different times when I can have one script handle multiple objects? Or am I not understanding your concern?
Hi Bruce,
Yes, no problem nice code sample, and thanks for taking the time to post it but I’ don’t want to get into arguments about the rights and wrongs of coding style. To long in the tooth (First mac in 1985 first apple II in 1981 first Cromemco Z100 CP/M system 1979 over 30yrs of academic computing and running my own software consultancy blah blah blah ). Seen too much time wasted on sites on subjects like that. I just wanted to know if I was right or wrong about how multiple buttons etc should be handled. Since making the post I have gone back to the ADC Ref Lib and checked the apple guidlines. These are quite clear and point out the handling of such events can be done either through multiple script files or within a single script depending on complexity of project. Similarly with NIB files single or multiple depending on structure of project. I think my problem stemmed from coming back to the Mac after completing a VB for applications project in MS Access. So let’s leave it at that and get on with… whatever!
thanks the Riverman
Looking back, I’d say that didn’t come across very well. Maybe it’s because I’ve done VB before and hated every moment of it. 
I don’t know of any technical or speed reasons why one would prefer either way. So, as you’ve found out, it depends on the project.
For example, take the project from which that code (see earlier post) came from. It has four different script files. One handles things like “will finish launching” (various setup or clean up stuff). Another script does the actual work, while a third script handles a couple buttons on the preferences window. Finally, there’s a script (which includes the code I mentioned) which handles some color wells and their corresponding text fields.
Obviously, with that code posted above, I don’t want to check theObject’s name, because I’d have to duplicate code. Thus, this piece was separated.
Fair enough lets call this thread closed.
Thanks again for your time.