Thanks for sharing this. I've not time to experiment just now but it occurs to me that a code note might help - see here, especially the latter part about using eval(). If the latter three inputs could be encapsulated like the AS script some of the quote balancing issues goes away.

Although a code note, used as a function of sorts, doesn't formally have inputs the calling note can always set the desired attributes in the code note (and zero them out when done). In pseudocode:

$InputA("a code note") = $Name;
$InputB("a code note") = $Text;
$InputC("a code note") = $URL;
... now evaluate $Text of code note using $Input values as input parameters
... then zero out values after
$InputA("a code note") =;
$InputB("a code note") =;
$InputC("a code note") =;

It occurs to me the above method could create a single Applescript list to pass to your export script rather than N separate variables.

Whilst this might seem like even more set-up up front, it goes to the same end that once set up, it is very easy to invoke the actual process desired as often as and whenever needed.

Thanks to both for the tips. The concept of feeding inputs into attributes of code notes is intriguing, Mark. How would that work in practice? Is the idea to feed the values into the AppleScript in the code note and just send the script itself to the command line, with values already substituted for the variables?

The way I understand it's working now is that osascript looks for separate arguments placed by the stamp on the command line and places them in a single AppleScript list accessed as item 1, item 2, item 3, etc. of the run handler (as described here). That's convenient, even with the current command line quoting tedium, which I hope eventually will be reduced by a friendly wrapper as a (presumably, says he hopefully) low-cost way to integrate Tinderbox better within the ecosystem of other Mac apps that support AppleScript to one degree or another.

On my machine the stamp works with and without the eval(). Not exactly sure why that could be the case. Will have to restudy the effects of eval().

Great tip on DEVONthink's display group selector, Paul. I was wondering how that was done. When exporting multiple Tinderbox notes at a time need to figure out how to call the group selector for the first note only and apply that choice to the other notes; otherwise it asks for each note.

As you say there are many possibilities, going both to and from DEVONthink (coming from DEVONthink can easily update the value of a Tinderbox attribute on the left side of a runCommand statement that runs an AppleScript).  And not just for DEVONthink and other applescriptable apps. This technique, for example, can easily be applied (it takes three lines within run and tell) to export a tab-separated-data table many apps can consume, leaving just the heavy-duty stuff, such as hierarchical structure or tens of thousands of notes, for Tinderbox export code.

Over here, Russ, the short answer is that DEVONthink is where I put .pdfs, .docs, images, etc.  Just as you use EagleFiler.  Why one vs. the other -- kind of off topic for here, but just a preference I suppose.   Tinderbox doesn't store docs, but excels at the creative aspect of working with concepts that DEVONthink can't handle.   I store my .tbx documents in DEVONthink groups (folders) alongside the other documents I'm working with.  I don't do much writing using DEVONthink.  I use it for research, do the early working out of concepts and writing in Tinderbox, then finish off in whatever editor is appropriate for the particular final work product I have in mind.

Thanks Sumner & Paul!

Got the code note working. Very slick using the display group selector! It was my first time using a code note, so it took a bit of reading and fiddling. Now I feel like I have much better way to exchange information  with DT (in conjunction with the DT explode to TB script.)

It would be nice to have a compendium of all the sorts of useful Applescripts that people have come up with for Tinderbox.

Lisa

@Paul

Yes, the looping and wrapping starts getting complicated for me, which is why I left it at incoming group, hoping experts here could show me the way .

The following, strictly speaking, is import rather than export, but still directly addresses Tinderbox-DEVONthink integration.

Quote:

You may have noticed working examples here and here that take advantage of TB's spreadsheet import to automatically create new notes with the links back to DEVONthink.

My minimalist approach to pulling the DEVONthink item link into an existing TB note is to place this in a code note named "GetDTlinkAS":

Code:

tell application id "DNtp"
	set mySelection to selection
	if the length of mySelection is 1 then return reference URL of first item in mySelection -- selection is always a list, so ask for item
end tell 

run by a stamp like this:

Code:

$URL=runCommand("osascript -e '"  +$Text("GetDTlinkAS") +"' ") 

enclosing the runCommand in an eval() if necessary.

This has no error handling but only does its thing after one and only one DT record and one or more TB notes have been selected.  It overwrites anything in $URL, of course, so change that to a new attribute named DtURI or whatever if needed.

@Lisa

I have a TBX with a collection of short AppleScripts that help integrate TB with other apps. Will clean it up and post elsewhere on the forum, probably after the holidays.

Thanks for the error checking tweak, which works well. For those who don't mind living a little dangerously, Paul's approach inspired an even more minimalist way to bring a DEVONthink link into Tinderbox, with just one line of AppleScript in the code note:

Code:

tell application id "DNtp" to return reference URL of (first item of (selection as list)) 

Nice tip on reference URLs for DEVONthink groups and smart groups, not just for individual records. Had no idea.  That will be useful.

The page you refer to documents the internal XML of a TBX.  If you want to access the RTF data you need to read and parse the XML. TB $Text in an action code sense is plain, unstyled text. A simple way to prove that is to style some $Text and then apply the rule: $Text = $Text. You'll find all the styling has gone.

I've no idea how/if this will change in v6 but if you've specific $Text-related needs it's probably worth writing directly to Eastgate explaining what they are.

It's worth adding that ^text^ outputs HTML-styled text but which is a subset of the styling available in a note text window. Off the top of my head, styling not HTML exported: text colour/font/size, highlights, sub/superscript - there are probably a few others. The reason for this 'partial' export supports is the style features either post-date the original ^text^ export design and/or don't easily translate to HTML. CSS wasn't the thing it is today when TB was first designed.