It is possible to drag individual notes, or whole selections/hierarchies of notes between TBXs. The result is always a copy. To move notes completely involves a drag/copy and then a delete in the source file. Dragging a container will carry along all its descendants.
You should consider these factors before starting such a drag/drop:
- User attributes. These will only be copied if the receiving TBX already has that user attribute correctly defined. Put another way, adding a note will not cause new attributes to be created in the receiving TBX. However, you can drag/drop attributes, so set up necessary attributes before dragging notes.
- Font face/size. If this has been set explicitly, the copied notes will retain the parent's settings, although the scaling set in the Preference Magnify Fonts does not transfer. If there is significant formatting but the wrong font is received in the target TBX, it may well be quicker to reset this via an edit of the TBX's XML source than by using the Font palette as changing a font also removes any bold/italic within the current selection.
- Note hierarchy/outline order. This is retained - i.e. all notes are inserted into the new location in the same relative outline layout as at source.
- Links. Any links connecting notes within the dragged set will be retained. Neat!
- System attributes. These are mostly transferred. Calculated attributes will be re-calculated for the location in the new document (e.g. $OutlineDepth, $SiblingOrder, etc.). Things like map $Xpos/$Ypos may vary. Simple attributes like $Color will be retained.
- Prototypes. If you wish to maintain prototype inheritance for the transferred notes, ensure their prototypes are transferred with the notes themselves.
- If a note has a prototype and the prototype is also copied then inheritance is maintained (but not for nested notes - i.e. it is only retained for top level siblings in the dragged set). Subsequent drags will fail to retain the prototype, even though it is already present in the target TBX. Dragging a second selection including the prototype, will work but a duplicate is created. The duplicate can't be deleted as the second set of items are linked to the second prototype, and so on. Plus you now have multiple prototypes with the same name - Tinderbox allows this but it's not desirable.
- Depending on the complication of the source TBX prototype inheritance it may make more sense to manually recreate the prototypes - or edit copied versions before moving the actual data.
- If notes with a prototype are regularly dragged between TBXs, consider making a Stamp for setting $Prototype to the desired value. After the drop, select the dropped notes and apply the stamp.
- Alternatively, either in the final destination, or in a container just to receive the drops, the $OnAdd can be set to make the $Prototype. If using a drop container, the notes dropped in it can then be moved to their correct final destination.
- An $OnAdd can't be used with nested drops as only the to level notes of the selection. In such cases, use and agent to target all notes descended from the container into which notes wil be dropped.
- In the preceding scenario, if the dropped selection contains notes with a mix of prototypes, consider the Stamp option. It will work where there are only a few prototypes between which to choose; make one Stamp per choice. For a more complex mix, add a user String attribute to store the prototype value, e.g. $SourcePrototype as an action, stamp or agent could easily set $Prototype = $SourcePrototype. In this last context remember to ensure the same user attribute is in both TBXs before dragging the notes across so the necessary user attribute data is retained.
- Individual Link Types, Colors, Stamps, Macros - see more detail
The number of notes that may be dragged concurrently is 250; prior to v5.5.1 it was 50.