display dialog "You need to select two and only two two different Apple Script files in the frontmost Finder Window or one file in each of the two frontmost Finder windows in order to run this script.
" with title "AppleScriptDiff" buttons {"OK"} default button 1 with icon (path to resource "Unsupported.icns" in bundle ((path to library folder from system domain as text) & "CoreServices:CoreTypes.bundle") as alias)
There is something odd right there icon or icon file, sometimes one works but not the other, I guess that is when I have made a file reference to the icon image up front, I’ll make a mental note about that!
Yes. The relevant labelled parameter of ‘display dialog’ is ‘with icon’. The value of this parameter has to be an ‘alias’ or ‘file’ reference. In your original code (and my variant), the ‘file’ is in front of some code which produces an HFS text path, so the overall effect is a file specifier.
Shane coerces his path to alias instead, which I think is slighty more efficient “on the fly”. This alias then becomes the ‘in bundle’ parameter of a ‘path to resource’ command, which in turn returns another alias. Putting ‘file’ in front of the result would cause an error.
display dialog "You need to select two and only two two different Apple Script files in the frontmost Finder Window or one file in each of the two frontmost Finder windows in order to run this script.
" with title "AppleScriptDiff" buttons {"OK"} default button 1 with icon (path to resource "Unsupported.icns" in bundle ((path to library folder from system domain as text) & "CoreServices:CoreTypes.bundle") as alias)
It is interesting to know that Shane’s coercing is faster, and to be reminded of the in bundle paramter of the path to command.
And yes, the file keyword, is a qualifier for what comes after icon in the display dialog command. (That the file keyword doesn’t work with a file reference is something to understand, that it doesn’t work with the alias is not so intiuitive, but maybe it is only Finder that takes easy on such matters.)
I wonder, why is there an own path to resource command, other than the obvious, to state in your code that you are getting a resource?
Is there any differences from this to the normalpath to command that I should be aware of, than merely the in bundle parameter?
Edit:
I see it is handy for getting into bundles, and that the directory parameter is taking a parameter relative to the resources folder of a bundle of an app.
Um, looking at the dictionary entries I see that ‘path to’ either takes an application name, or some variant of that (like ‘me’ or ‘it’), or a folder designation (not same as its name) from a predefined (and fixed!) list.
So you can use ‘path to’ on applications and (specific) folders, but not on other bundle types.
That’s where ‘path to resource’ comes in, with ‘in bundle’ to plunder any bundle whatsoever, privileges permitting.
My final words is, that when it comes to at least icon resources then I prefer the a reference to file to an alias because then there isn’t any alias to resolve during the awakening of the dialog. I don’t know if this can be felt, or timed, as our cpu’s performs several billions instructions per second, nowadays, and SSD disks are also around…
But at least, it feels faster, when you know that the icon file doesn’t have to be resolved during the display of a dialog.
So my favorite for displaying icons in dialog boxes are:
set my infoIcon to a reference to file ((path to library folder from system domain as text) & "CoreServices:CoreTypes.bundle:Contents:Resources:AlertNoteIcon.icns")
alias ((path to library folder from system domain as text) & "CoreServices:CoreTypes.bundle:Contents:Resources:AlertNoteIcon.icns")
--> alias "MacBook Pro HD:System:Library:CoreServices:CoreTypes.bundle:Contents:Resources:AlertNoteIcon.icns"
((path to library folder from system domain as text) & "CoreServices:CoreTypes.bundle:Contents:Resources:AlertNoteIcon.icns") as alias
--> alias "MacBook Pro HD:System:Library:CoreServices:CoreTypes.bundle:Contents:Resources:AlertNoteIcon.icns"
a reference to file ((path to library folder from system domain as text) & "CoreServices:CoreTypes.bundle:Contents:Resources:AlertNoteIcon.icns")
--> file "MacBook Pro HD:System:Library:CoreServices:CoreTypes.bundle:Contents:Resources:AlertNoteIcon.icns" of «script»
But (in Leopard and Snow Leopard):
file ((path to library folder from system domain as text) & "CoreServices:CoreTypes.bundle:Contents:Resources:AlertNoteIcon.icns")
--> error "Can't get file \"MacBook Pro HD:System:Library:CoreServices:CoreTypes.bundle:Contents:Resources:AlertNoteIcon.icns\"."
But again:
read file ((path to library folder from system domain as text) & "CoreServices:CoreTypes.bundle:Contents:Resources:AlertNoteIcon.icns") as data
--> «data rdat69636E73000063A249434E230000010800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000FF800007FFF000. etc.
The above phenomena are true with any kind of file, not just system icons.
With regard to setting up and using file references, I haven’t been able to find any reliable difference in speed between using ‘file blah’ and ‘a reference to file blah’. But they’re both definitely faster than ‘blah as alias’, which in turn is faster than ‘alias blah’. My earlier assertion that a coercion to alias is more efficient than a run-time file specifier must have been confusion with the fact that it’s faster than a run-time alias specifier. File specifiers are fastest, although they no longer appear to exist.
I don’t doubt you, but these days I think it’s worth adding a rider about the OS used for testing – as you’re seeing, there have been changes under the hood on what constitutes a file.
I’m not sure if it’s just a transition gone wrong or not. If you call, say, choose file name, the result appears as ‘file “Blah:blah”’, but its class is «class furl». It looks to me like «class furl» has been given the term file, but that the older «class file» still has it too.
I just want to add that I was writing about feelings but it was in a script consisting of a little less than 2000 lines at the time being, from within Script Debugger in Debug mode.
I don’t think I can’t notice any difference anyway, when the script is running, though the file refrence, drags a little less resources. and furls are ok, as long as file references stay!
But then again, I like the screen updates to be as crisp as possible, so I will use the filereferences for icons anyway.
But you have to have rather quick reactions, to spot any difference, in this snippet!
set infoIcon to a reference to file ((path to library folder from system domain as text) & "CoreServices:CoreTypes.bundle:Contents:Resources:AlertNoteIcon.icns")
set unsuppicon to (path to resource "Unsupported.icns" in bundle ((path to library folder from system domain as text) & "CoreServices:CoreTypes.bundle") as alias)
tell application "SystemUIServer"
activate
display dialog "Hit Enter" with icon 1
display dialog "You hit Enter" with icon infoIcon
display dialog "Hit Enter" with icon 1
display dialog "You hit Enter" with icon unsuppicon
end tell
I wonder if you know about any more updated resource on the subject matter?
I see code where people address System Events with “syscve” or similiar, and also sending «event Pcap» I wonder, if this partuclar lore can be found somewhere, or is there just tid bits floating around?
You can hunt through the header files, or just look at code in Script Debugger showing raw syntax. But of themselves, they’re not particularly enlightening.
That is so true, about enlightening, and must I add interesting. But sometimes, there are gems to be found, like the trick by running a script to make something into a format that for example finder will take, with lists with keywords and specifiers that finder will understand, and accept. Or the trick by throwing an error to get read access to a datstructure, that are otherwise consealed, by reading the error string.
Sometimes, things can only be accomplished by a trick, and then it is good to know where to look for it!
And sometimes, you want sheer speed, not that it is neccessary at all times, but when the system is bogged down, then it helps, both to the robustness, and the responsetimes.
That is the only thing I can see as a liable excuse for using the more arcane language constructs.
By the way I figured out by some googling, that the alternative application id, was the applications creator type, that it can be used as an alternative for the bundle identifier
On my way I also learned that the bundle identifier of apps may vary with whether they are bought in the Appstore or not, and that holds for the creator type as well.
I have updated the script for Mavericks, TextWranglers path to twdiff has changed, I have also removed references to my “coreLibraryLoaderServer”, as with some new technology, and pretty much before that, it was obsolete. Lots of work to make it work, and it still does! But not worth the effort, in any sense.
The script still decompiles two applescripts, and puts it up into TextWrangler, so you’ll need TextWrangler for this one, and the command line tools installed.
P.S If you had the commandline tools installed before you installed Mavericks over your old operating system, then you may have to reinstall them. I had to at least. If this script doesn’t seem to work, then please visit a terminal window and execute the command which twdiff.
This is a version that shows the differences between two AppleScript files with FileMerge. Maybe I should have coalesced the two into one script, but then you’d have to do more than simple executing the script.
Removed a bug in the Script in post #26 The bug wouldn’t kick in, until you tried to compare something different than a file with a filetype of “osas”, -it took five years before I did just that, and realized, there were a missing handler in there. The issue is fixed.