Eventhough I have been using Tinderbox for a long time only recently I have started to use the adornment function. I got inspired by some recent postings that discussed the use of this function for course planning. Since course planning is always a bit of a drag for me, I thought using Tinderbox could make the task both more fun and more productive and efficient.
One of the biggest obstacles I have found is that there seems to be a undesirable interaction between adornments and containers. As far as I know, adornments only exist in the Map View and they are just a visual tool. That means that in principle the association of a particular note to a particular adornment in the map view should not affect the way the note is classified and stored in the data base underlying Tinderbox.
Hereās what happens, though. I have notes organized in different containers but when a note meets the requirements to be part of a particular adornment in the Map View and moves to that adornment, it loses its place in the container where I had put it in the outline view.
Let me give you a specific example to make it clear.
I have a list of readings classified under a container called āREADINGSā, within this container there are other subcontainers with different types of readings. Finally there is a note for every reading with a summary and other relevant pieces of information.
In the Map View I made an adornment called āCURRENT WEEKā. In that adornment I created a query with a particular āDueDateā. The idea is that the different notes for particular readings or particular tasks with that due date will flock to that adornment when the condition is met.
This worked very well in my first test but when I go back to the outline view I notice that all the notes that went to that adornment are now outside their original containers.
I canāt quite follow at which level the adornment is placed (at the top level ?). Have you got an example document that you can share to illustrate ?
Itās important to remember that documents have hierarchies (the outline), and maps āexistā at one level of a document hierarchy. Your query is moving notes out of one level of the document hierarchy (i.e., they are inside a container) and up (or down) to the level of the hierarchy where the adornment resides on that levelās map.
You might want to reconsider the structural design of your document. (Perhaps flatten it?) Or perhaps use aliases on the map.
But, where is that adornment, i.e. in which container.
After some time testing i canāt replicate this. A smart adornment, i.e. an adornment with a query, can only move notes in the current map. It therefore canāt move note out of a different map (i.e. container).
Iāve used a very specific query. By your description, note āaaaāāa grandchild of the current map, would move to this map and onto the adornment. Except that does not happen.
I suspect youāve other things in your document that youāve overlooked. In this situation, I accord with suggestions already made above to upload a small TBX that demonstrates the problem. Indeed, the task of producing the test document may help you discover what it is you are presently overlooking.
OK. I see this was a misunderstanding on my part. Adornments are described as a functionality which is used to provide a means of adding visual elements to the background of the Map view. I took the term āvisual elementsā to imply that whatever you did with an adornment had no implication whatsoever for the structure of your containers and nodes. That is, when you āmoveā a note into an adornment, nothing actually moves there; it is just a device that allows for some alternative visualization of your data which is independent of the way in which your data is actually structured.
I donāt know if I make myself clear but imagine that you could create adornments that donāt live in any specific containers and that when you made them āsmartā they could gather notes from whatever container without actually affecting their actual location. [edited: see end of message, I now see that this is actually what can be accomplished with an Agent]
Now I know that this is not so and that, whether they are just visual elements or not, they āliveā in the specific locations where they are represented in the map view (that is, in a specific container). In principle, though, what I thought it was might also be possible (I think) and it wouldnāt be a bad feature to have. As Paul Walters has suggested, perhaps you could do this with aliases, but it would be a bit more cumbersome.
Anyway, thanks a lot for clarifying this for me. Now Iām no longer confused.
After having written this message, I realize that what I had tried to do with adornments can be done with an Agent.
