Hi, I would like to something I thought would be quite straightforward but am tying myself in knots a little. I’d welcome help.
I am trying to make more use of dragging items (Emails, URLs) into Tinderbox and then, as much as possible, having Tinderbox automate the process of cleaning up the text, ensuring AutoFetch doesn’t later override this cleanup, add some KeyAttribute and moving the items to the right place. This would be a neat way to store content I want in Tinderbox as I browse.
But the behaviour seems a little different to what I thought would happen (as with, for example, Watched Folders.) I had assumed that using agents and prototypes, I wouldn’t have to do too much apart from a little formatting to the note.
When I drag across an item, the note appears fine once the AutoFetch does its work. But I see URL becomes the only KeyAttribute – whether or not I have dragged it into a container where OnAdd dictates notes should adopt a Prototype to include other Key Attributes. The prototype has been correctly assigned, but the Key Attributes of the prototype are not visible.
So even if I move the note, or have an Agent move the note, or even try to assign the note a Prototype the KeyAttributes of the prototype don’t appear. This leaves me with a note still AutoFetching (and overwriting my changes) and without the KeyAttributes I’d like to see.
So what am I doing wrong? I thought there might be a prototype generated, as per Watch Folders, that I could tweak. But perhaps there’s something I’m doing wrong, or there’s a simple fix I haven’t thought of. Help as ever much appreciated.
(I would love to understand the AutoFetchCommand better, too. I really liked this trick from mark @eastgate but I don’t claim to understand what it’s doing, exactly.
I’m a bit confused by the reference to AutoFetch here, as it sounds nothing like actual AutoFetch. This misunderstnading may be part of the issue above.
For instance, when dragging an email (form various email clients) to Tinderbox we get a variable outcome as described here depending on source email client. There is no AutoFetch involved in this process.
Given the above, could you expand on what specific things you are expecting to happen but don’t. Given that we can turn this from an open-ended report to an answerable question.
That is entirely consistent with Tinderbox inheritance, which it might help you to re-visit so as to clarify some false assumptions stated above.
If you drop a URL on a note is sets the value of $DisplayedAttributes to “URL” and in doing so replaces the existing value, be is default (nothing), inherited (a list of attributes), or locally set ((a list of attributes).
Dropping something—that is not a note— onto a note or view has nothing to do with $OnAdd which is an action that fires when a note (or container, etc) is moved manually or via an action inside another note. If you drop an external object onto—for instance, a map inside a container with an OnAdd—it is not clear whether the parent’s OnAdd is applied to the new note before or after the drop-related activity (setting $URL as a Displayed Attribute).
It’s not clear where you are turning on AutoFetch. Can you give more detail?
I don’t think you are doing anything wrong as such, but you clearly have some incorrect assumptions about how inheritance and the dropping of external data works. So its misunderstanding not error.
At this point, what I do is hit up Help, aTbRef†, and other tutorial materials to [test my assumptions. If having checked out those and behaviour still seems incorrect [sic] then it might be time to ask support. If it’s just a case of not understanding what is described, then here is a good place to start, though it helps those answer a lot if questions aren’t open ended. “Something I didn’t expect has happened” will generally mean a host of follow-up to get the the real question underneath.
A case in point, as it’s not clear you are actually using AutoFetch in the way Tinderbox means it.
†. That might seem odd given that I write aTbRef. But there is a lot of detail in that resource, all written a little at a time—written of 16 years—about features I myself may never use outside testing documentation. Indeed, it is answering questions like this that keep things fresh (in answering this I’ve already made several small edits in aTbRef, even if only clarification or fixing stray formatting). Tinderbox is not a single-context/single-task utility but a toolbox. Once one has found the tools in the box one withes to use most often it pays to then revisit available documentation about them. Not least, things change. I started writing aTbRef in early 2005: both Tinderbox and its host OS have changed a lot since then!
