That was a good idea, which I implemented, I was going to, but since there was a requestâŠ
I will use this together with some scripts for using the RCS (included) version control system with AppleScript a tad later.
I also removed some errors due to the fact that i did forget to remove the references to my script object when I âflattenedâ it.
Edit:
Iâll make another version for plain text files of any kind a little bit later, as this is as useful as this, and easier than putting the files into FileMerges trays.
Edit+I will come back soon and turn it into a general script, where a file is converted into text by its Uti, so that you can see differences in an rtf file and a word file for instance.
I have updated the Script to take files from the two frontmost finder windows. -A bit more practical.
I have also added an icon to the dialog which displays error messages. Please ensure that the hard drive name corresponds with yours. (âMacintosh Hdâ)
The âpath toâ command can save users having to do that:
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 file ((path to library folder from system domain as text) & "CoreServices:CoreTypes.bundle:Contents:Resources:Unsupported.icns")
Or, unofficially:
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 file ((path to "csrv" as text) & "CoreTypes.bundle:Contents:Resources:Unsupported.icns")
Thank you very much for pointing that out! I have fixed, I probably have some others here, but Iâll take them when they show up, at least for now.
I tend to do it your way nowadays, it is so much more practical!
About the codes
Is there a place you can find all those âunofficial codesâ I believe I have seen people calling application âsyscveâ for instance. and it would be good to have that knowledge, that is, if there is a compilation somewhere, or if they are all from a system doc.
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")
Yuk! I wish I hadnât looked at this this morning!
As expected:
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.
OYOH, âas «class furl»â seems to work nicelyâŠ
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.