Oh yeah. Large PDF for $10. Extraordinarily good value. The repetitious boilerplate in the examples take up space and attention unnecessarily, but otherwise the code in the many examples is excellent. The author states that there are topics not covered, but the fundamentals and lots more are here.
I disagree. I often use the book as a reference, and having complete examples in the section I am reading are very helpful.
Well, if nothing else, he could have left out
use AppleScript version "2.4"
use framework "Foundation"
use scripting additions
from the beginning of what must be hundreds of scripts in the book. The scripts wouldn’t run as they appear in the book, but complete scripts are in the folder accompanying the book.
@MitchellModel, I moved your off-topic review comments, and all replies, to a new topic.
Your comments about Shane’s book are not relevant to the Macro that was posted.
Another comment about repetitive code, followed by high praise.
There are many examples done two or three ways. I would have preferred if examples after the first either just showed the changed lines or highlighted the changes. But so what, I guess.
I might have agreed with you in the best, except for recent experiences:
While trying to learn JavaScript and AppleScript, I would come across example after example of code snippets that assumed you already knew what the surrounding code was supposed to look like, where you were supposed to use the snippets, etc. Now I’m grateful when examples show everything.
And I realize a book is different than Internet posts, but still, that’s where I come from now.
This is a truly amazing book. It goes way past ASObjC. it explores a great deal of the important Objective-C libraries and shows how to use them. (The names of methods in Objective-C are ridiculously long, which means that code overwhelms the discussions, but that's not the author's fault. Even with all my long experience with OS X, AppleScript, and Objective-C, I learned a lot about the languages, libraries, and even OS X.
Have you ever tried wrestling .plist files out of the way? For instance, I sometimes want to rename my ~/Library/Preferences/loginwindow.plist so that the next time I log in none of my startup applications run. If you have System Preferences open, this is pointless, because loginwindow.plist will just be recreated. OK, so I know to quit System Preferences before moving login.plist out of the way, but sometimes shuffling preference and application support files doesn't work quite right. Curious about how this all work? Here's what's going on.:
[pg 104/148]
…will now contain a defaults object, which automatically synchronizes with a special defaults daemon process. When you launch your application or run your script, the defaults object will ask the daemon for the values for its identi er, and it will load them (if it hasn’t already). At some stage a er you quit, the daemon will save them to a property list le in your preferences folder. You communicate with the defaults object, and it handles the rest automatically.
… e defaults process runs all the time, so once it loads an application’s preferences, deleting the preference le is pointless; the values held by the defaults process are what matter, and they will usually end up being written to disk again.
This is deep and remarkable. The book is full of this sort of information. The material on bridging is really only a small part of the book's contents, despite its title. It doesn't, of course, cover interface building, but there is even a fair amount of simple user interface information. Otherwise, there is just about everything here that you would need to write significant scripts and applications using the AppleScript language and Objective-C libraries. It should have been called something more like Everyday OS X Programming Using AppleScript with Objective-C Libraries