Show differences in two AppleScript files with TextWrangler

Hello.

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")

Hello Nigel! :slight_smile:

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.

/System/Library/Frameworks/CoreServices.framework/Versions/A/
Frameworks/CarbonCore.framework/Versions/A/Headers/Folders.r

. but don’t get carried away.

Edit: Path split into two lines to make it all visible in the forum window.

Thanks a whole lot! :slight_smile:

I am not intending to use it, but it is good to be able to understand what is going on at times, when people has resorted to this practice.

My personal views on this is that the codes should be avoided, if there exist other alternatives.

But there is sure many codes in there, that there aren’t many alternatives too. :smiley: Interesting!!!

Having said that; those codes, that is one thing, raw events in code, a totally different one, but I guess it is sometimes necessary.

Or even:

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)

Hello! :slight_smile:

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.

Hello. :slight_smile:

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.)

It’s actually the path to resource command. There’s no in bundle parameter with path to.

Hello.

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 normal path 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.

Anyway, that’s my €0,02.

Hello!

This horse is beaten to death, I know! :smiley:

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! :expressionless:

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. :confused:

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! :slight_smile:


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

Interesting. Thanks for the insight.

Hello!

I came by this document on the net, from 1997.

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. :smiley:

I found that part in http://forums.omnigroup.com/showthread.php?p=98911