New page Address documents not windows covers a perhaps counter-intuitive tell block issue where in most cases you address the document rather than the document window within the document: this might differ form a similar context when scripting other apps.
At the last meet-up, @eastgate noted that when fetching attribute values from linked notes, the newer (v9.1.0) eachLinks() may be more helpful than the older (v4.0.0) links(). The latter is not being deprecated and there is no need to go and change existing working code. The suggestion is there more for those writing new code. So, I’ve cross-linked the two pages. If asking why this is the case, ask in a new thread as I’m not 100% sure myself (I find links() easier, but I’ve 20+ years of Tinderbox use). BUt as asked, i’ve cross-linked the articles on those two operators.
This is not a full update, but the affected web pages have been uploaded as have the site map, search index and the TBX zip.
Many thanks for this. When you next revisit the linked AppleScript entry perhaps you could consider removing the remark (for a brief time true, I think, but no longer) that one can’t set the name of a new note in the same line of code as one creates it.
Also, to my way of thinking it doesn’t seem “roundabout” (at least not in an AppleScript context!) to find a note or reference its container.
Consider this code:
tell application "Tinderbox 10"
set myNote to find note in front document with path "Note 1/Subnote"
make new note at myNote with properties {name:"My New Note"}
set parentContainer to parent of myNote -- grandparent of new note
end tell
Also I don’t think a repeat loop is needed to conduct some “bulk” operations on all selected notes.
The example given works:
repeat with anItem in selection of front document
set value of attribute "Color" of anItem to "red"
end repeat
But so does this:
tell application "Tinderbox 10"
tell front document to set color of selections to "red"
end tell
I was confused by the separate entry about windows. Usually one references a document first and then an object within it. Tinderbox follows the norm, if there is such a thing as a norm in AppleScript!
On the main AppleScript page I suggest removing the statement that Tinderbox offers “limited” AppleScript support. It’s highly robust support! And when you add to that the ability through ‘evaluate’ to run native action code, the support is even more impressive.
All points well made, and I’ll action. I welcome this kins input from someone with deeper AppleScript experience. The ‘limited’ support was meant to indicate not every possible in-app feature was scriptable. I’ll rewrite the to better explain the point.
The window came about because I had some old scripts that used the metaphor of tell front window of front document. In v6+ Tinderbox the call goes to the document and a window call is both redundant and AFAICT causes the script to fail.
In turn, a reason for addressing that is I’m trying to write AppleScript examples that can be assumed to run inside a common tell wrapper. So for the less export, the code sample can be copy pasted into that wrapper.
Perhaps I need to re-factor the whole AppleScript section in aTbRef and start by addressing the (assumed) tell block in use. The presumption being that a user new to AppleScript (or using AppleScript with Tinderbox) would be instructed to read that part before looking as the small code examples.
I’n genuinely open to suggestion here as the point of the content is to help users wanting to ‘talk’ to Tinderbox via AppleScript. So (further) suggestions will be gratefully received!
I think DEVONthink scripts often “tell” a window, called (I think) a ‘think window’. I’m thinking the comment about windows originally may have been influenced by that. Or maybe by a “gui-script” in the days when only that was possible with Tinderbox. I vaguely recall you had a nifty web clipper that may have addressed a window before pasting. In any case, now there is potential to confuse.
The aTbRef articles are most helpful in pointing out the way to put the focus on a note. That is highly specific to Tinderbox, thus not obvious. Not at first being obvious is of course nothing unusual in AppleScript!
According to the Tinderbox AppleScript dictionary, ‘find note in’ is always followed by a specifier, which can be either a document or a note.
If the script has “told” a document (but not “told” a note) then ‘it’ is needed to specify the document. That seemed awkward to me at first (wait, what exactly is the antecedent?). But in AppleScript ‘it’ typically refers to the object that the current tell block is addressing, e.g. front document.
Sometimes omitting a tell block results in more natural language.
This works:
tell application "Tinderbox 10"
tell front document
set notePath to "/Note 1"
set theNote to (find note in it with path notePath)
evaluate theNote with "links.inbound..$Name"
end tell
end tell
But this may seem more natural:
tell application "Tinderbox 10"
set notePath to "/Note 1"
set theNote to (find note in front document with path notePath)
evaluate theNote with "links.inbound..$Name"
end tell
In any case, Tinderbox has solid AppleScript support for getting data from/to a wide variety of apps. Until something better for that than AppleScript comes along (not in the offing, it seems) it’s a great thing to have.
I’m taking on board all your comments and may re-do the whole aTbRef AppleScript to better capture these nuances. They are useful both to the new AppleScripter and those used to using AppleScript.
A question for @sumnerg: given that Script Debugger now has a free mode and is so much more helpful to a user, does it make sense to suggest use of Script Debugger rather than the OS-bundled utility Apple Script Editor? For instance, I notice the latter needs to user to know to add Tinderbox to the library before they can see the ‘api’ on offer. Those with least experience have a hight hill to climb.
I ask the latter as I think a note on some debugging tips might be useful. I suspect many users only ever copy/paste the odd AppleScript written by others compared with the few who make deep use of such automation. This isn’t helped by Apple’s ongoing disregard for AppleScript; if it weren’t deeply/expensively embedded in the design/print/creative layer likely we’d have lost AppleScript years ago. I don’t see the iOS-styled Shortcuts app as any real form of replacement, but just appeasing those devs who want to write for one UI (dev effort costs vs. UX).
I have Script Debugger, which has been helpful at times, especially when serious about learning AppleScript and trying to do “complex” things. Their forum can be useful. I didn’t know they now have a free version.
For the occasional scripter, good old Script Editor has the advantages of being lightweight and handy, and being able to do JavaScript. To pull up the Tinderbox dictionary I don’t think I had to add Tinderbox to the library. I think all apps with scripting support show up automatically. I just File > Open Dictionary… and scroll down to Tinderbox 10.
Becoming comfortable “reading” the dictionary well enough for it to make enough sense to be useful takes time, and for me a lot of poking around and trial and error in a way that undoubtedly would horrify developers. With AppleScript, those without a coding background and preconceptions, but a willingness to poke around and seek out examples to emulate and “make them work” for the task at hand, may sometimes do almost as well as those who actually know what they are doing!
Two more random thoughts to consider when you revisit AppleScript section in aTbRef:
If it seems awkward to use:
set targetNote to (find note in front document with path "Notes/Note 1")
set value of attribute "MyString" of targetNote to "test"
Then one can use more vanilla “AppleScripty” language to construct the path:
tell front document
set targetNote to note "Note 1" in note "Notes"
set value of attribute "MyString" of targetNote to "test"
end tell
In the ‘Evaluating Expressions’ entry, perhaps it would be useful to make more explicit the idea that “one can run Tinderbox action code from AppleScript.” That means one can do many things “to” Tinderbox that aren’t explicitly in the normal AppleScript dictionary. It also means one can do things in Tinderbox not easily done elsewhere and get values back out for further use outside Tinderbox, if wanted. That is a uniquely powerful combination supporting AppleScript’s usefulness as a “glue” between applications.
Thanks. Both really useful suggestions. As regards the ‘find note in’ method, it does seem the most flexible, if not the most intuitive at first encounter. I note this as that second method presumably is less capable for longer paths (and where note $Name is not known to be unique)—or am I misunderstanding? To take a deliberately difficult edge case, what is we want to identify ‘note 1’ at path /Notes/Notes/Notes/Note 1?
The point about evaluating expressions is well made. i’ll find better text.
[apologies this is still on the spike, in terms of actual live articles, but i'm a bit snowed under with deadlines for papers, etc.]
tell front document to return value of attribute "Text" of note "Note 1" in note "Notes" in note "Notes" in note "Notes"
And:
return value of attribute "Text" of (find note in front document with path "/Notes/Notes/Notes/Note 1")
I constructed a similar path later in the outline.
They both work! IF that is the first time Tinderbox encounters that chain of ancestors (/Notes/Notes/Notes/) in the outline.
But if it is not the first time, then they both fail my quick tests.
It seems that find note in [specifier] with path [text] is not smarter about paths than the more natural (at least for shorter paths) note "NoteName" in note "ParentName"
In due course recommend including that approach too.
Sorry to hear about the (eventual) demise of SD. I didn’t realize MacScripter.net was related. I think I read that they plan to keep that going.
Thanks, added to my pile of notes for updating the AppleScript articles.
It seems SD and MacScripter will run on in maintenance if nothing else. So the trove of info at MacScripter may persist longer than SD as ongoing OS changes will likely nibble at the app’s ability to integrate as in the past. As likely most Tinderbox-related use employs the simpler parts of SD so it should be useful for a while yet. And it will be free, not that I think my past licence costs were a waste!
