News:IMPORTANT MESSAGE! This forum has now been replaced by a new forum at http://forum.eastgate.com and no further posting or member registration is allowed. The forum is still accessible via read-only access for reference purposes. If you wish to discuss content here, please use the new forum. N.B. - posting in the new forum requires a fresh registration in the new forum (sorry - member data can't be ported).

I understand from what I've read here that in in version 6 and above, it isn't possible to drag items between different windows in the way one could in in previous versions. So I'm wondering what the best alternative would be for when I want to move a group of notes from one part of an outline in one window to a very different part of the outline in another window. Should I manually change the parent note? Or just cut and paste? (I should note that I do need to preserve the original note creation timestamps.) There's probably some obvious way to do this --- I just always relied on drag-and-drop in the past, and now I'm drawing a blank. Thanks for any help!

Great, thanks. I guess I was nervous about the the "cut" part of cut-and-past, but it works just fine. (Indeed, much of the time it works to just drag within a single window, but sometimes with complex outlines it's handy to work with multiple windows that are focused on different parts of the outline, and cut-and-past can come in handy.)

I guess I was nervous about the the "cut" part of cut-and-past, but it works just fine.

Here is the only obvious-once-you-think-about-it potential pitfall with cut-and-paste. If you're moving things from one container (or, section of an outline) to another, and if that new container has some On-Add Action that you've forgotten about, the results could be different from what you're anticipating. Don't ask me how I know this.

Also, if you're worried about the "cut" part (as I often am for atavistic reasons, despite Undo and so on) you can always do copy-and-paste, rather than cut-and-paste, and then go back and delete the originals once everything is safe and sound.

Hello all. I just today made the switch to TB6. The new iMindMap-like broad style link arrows looked so attractive that I actually upgraded to El Capitan just so I could run 6.5 and admire them. (I was also hoping that running under the latest OS would also help TB6 preserve window sizes and positions, which was the reason I'd stayed with TB5 for so long. Alas, this is not the case.)

The first thing I noticed was the demise of between-window dragging.

Using cut and paste as an alternative works great. Unless the note you're moving is an original that has aliases. In that case, cutting the note will kill all aliases.

I'm guessing that the only workaround is to switch to Outline View, unhoist until the destination container is visible, and then drag the original it to the destination container. Is this correct?

If we want to move a note within the same document from one window to another, I believe we must use cut. I'm worried now whenever I do a cut because if any of the notes inside the cut note have aliases elsewhere in the document, they will be deleted (and will remain deleted after I paste).

Is there any way to move a note between windows without losing all aliases?

UPDATE: Copy the note A in window A. Paste it window B. Then delete the original in A. I think this should solve the problem. But what about links from A?

I know it's not a copy/cut approach, but don't overlook action code and setting $Container. Setting a new $Container value for a note moves it to the container stipulated - and any links, etc., would be maintained. Not tested, but I assume the new container's $OnAdd would be triggered - in case the latter might be an issue, though a 'drop' into a container would fire $OnAdd too.

To move a note (or selection) for container A to container B use this code:

$Container = "B";

…where 'B' is the $Name of the new container. If $Name might be ambiguous you can always give the full $Path instead.

This code could be used in a $Rule, $Edict, stamp, adornment $OnAdd, etc. If using in an agent's action you must set the $Container for the original or else you simply move the alias out of the agent. thus for an agent context:

Thanks for pointing that out Mark A. I just tested copy and paste. Copy, too, deletes incoming links.

So it looks like notes with links or aliases cannot make the journey across windows. Good thing notes now display incoming/outgoing links in Outline View. Is there any way to know from the icon which notes have aliases and which do not? If not then it looks like dragging within the same window and in Outline View is the only safe way to go for now. That will mean lots of outline-expanding and scrolling for deep files.

Aliases aren't particularly easy to track as, for good reason, most searches try to disambiguate and return a single reference to an object even if it has many aliases. The best option is to use find() as this doesn't de-dupe results - indeed you have to filter if you don't want pointers to original and aliases.

I suggest you make a note - not an agent - called 'Alias Checker'. Make $MyString and $MyNumber a key attribute. Give the note this rule (or edit if you prefer):

The rule presumes we enter the $name of the note in which we're interest in the alias checker's $MyString; the '[url=]that[/url]' designator lets us use the value in a query. In the rule, firstly find() will return the path ($Path) of all notes and aliases whose $Name matches that test $MyString value. The query is full document scope - you could narrow this with additional terms. For instance if you only want to return aliases and not originals, add '&$IsAlias==true' to the find query; this will cause the original of the searched-for title not to match.

An assumption here is that the note $Name is unique, i.e. the additional matches are all aliases. If that's not the case you've a more complex case to solve. Another assumption is you're not looking for adornments, these are not query-able (or so I understand it).

The second expression in the rule stores the number of matches in $MyNumber. If the number is 5, that tells you you've a note with 4 aliases. If you want the $MyNumber to give the alias count, adjust line #2 of the rule: $MyNumber = ($MyList.size)-1;

The last part is optional and helps if you want to know where the aliases are, as it sorts the paths and places them in $Text as discrete lines (paragraphs). You can't tell at this pooint which is the original. If you really just need the aliases, use the modification to the find() query I mention above. If you just want a count, you can delete this last part of the rule.

Lastly, when using this it's probably a good idea to set $MyString to "" and let the $MyList and $Text flush back to nothing and then disable the rule (easy via the rule Inspector's tick-box. This stops hidden data piling up, and running one more whole scope query that doesn't need running all the time. That said, as we're storing info about aliases rather than creating addition ones, it has no effect on the number of aliases.

Writing all this makes me thing that having a $AliasCount might seem a useful addition. Still the above is not hard to do, and a count wouldn't tell you where the aliases are. We've already got >300 system attributes to wade through when looking for the one we want. Note: don't worry about the latter figure, TB only stores (to TBX) non-default values for system & user attributes. Having greater or fewer system attributes in the app doesn't significantly affect TBX size.