I noticed that cut/copy-and-pasting a note updates $Created. I expected $Modified to be updated but $Created to be a persistent property. I understand that from a software perspective the pasted note is a new entity. However, in so far as a note represents an idea, xeroxing it does not make it new.
After I wrote the above, I found this exactly opposite view
Any suggestions on how to paste while preserving $Created? (This reminds me of special paste operations in other applications, such as Excelâs paste-value-only or Wordâs paste-matching-style.)
$Created is a read-only value. The only way you could change the value would be to edit the TBX documentâs source XML outside the app.
If you want the same note in different places in the document, consider using an alias of the original note. Select the note and use menu Edit ⸠Make Alias (â+L). The alias is created alongside the original and an then be moved anywhere in the document. Do be aware of the concept of intrinsic attributes in case that matters. for those who think aliases are just a facet of agent use, this shows that most Tinderbox objects (adornments being one exception) can be âmanuallyâ aliased.
Otherwise, track a different attribute. What? You say want to track read-only $Created for whatever reason, yet as you note you canât be sure $Created is always correct for your purposes in all cases.
So, as a new user Date-type attribute $MyCreated. Now, for your main content containers add this $OnAdd:
$MyCreated = $Created;
You can use the same code in a stamp to âupdateâ any pre-existing notes. Now you can also design a method for setting $MyCreated in copy/pasted versions of the notes.
Thereâs insufficient info to detect further, but it feels like your use if $Created may be building on a false premise. If youâre open to sharing a bit more of the problem, the community here might be able to help. Itâs not that using $Created values is wrong but simply that youâve been caught out by untested assumptions about how $Created behaves (when a note is copied.
FWIW, I do think the current $Created behaviour is correct. It records the date/time that note was created. An alias will use the original noteâs creation time. As an alias it is the same note in a different place. But a complete copy of a note when pasted is a new note. It simply wouldnât make sense to record the creation time of a different note in $Created as they werenât created at the same time even if the two notes share many other attribute values.
In summary, aliases or employing a user attribute offer you at least two different alternate approaches to avoid the false assumption youâve tripped on.
When a user copies and pastes, the intent is to have 2 versions. Since the original remains, it makes sense that the new one refreshes $Created. If one wanted to duplicate without changing $Created, an Alias is a good alternative.
However, when a user cuts and pastes, the intent is different. I suppose one could be cutting and pasting to update $Created, but this seems unlikely. More probable is that the note is being moved. While its location has changed, $Created probably shouldnât.
If macOS kept track of whether an item in clipboard was cut or copied, one could could tailor paste-action.
I had considered making a separate date attribute but thought I might see if there was a simpler built-in solution.
It this is the case, then I would just move the note either by dragging and dropping it into the desired container or by changing the path in the notteâs $Container. The path can be changed by a Stamp, which is what I do sometimes, especially when I have a larger file. You could do it in a two Stamp process. For example.
Create a note called TBXConfig to hold the value where you want to move your note. I use a TBXConfig note for a lot of operations, this being one of them.
Create the destination Stamp.
$DestContainer("TBXConfig")=$Path(this)+"/";
This stamp sets the value of the attribute of $TBXConfigâs $DestContainer to the path of the selected note.
You select the note you want to move the other note.
Move one or more notes
Select the notes or note you want to move and apply the âMove Noteâ:
$Container=$DestContainer(âTBXConfigâ);
This will pull the destination path from the TBXConfig note and then move the selected notes.
For me, the big lesson here is the use of the designator âthisâ and the assignment of a value to a note via the parenthetical operation by entering in a unique note name, note ID, note path, or variable. This can be a big leap in logic, but once you understand it it really opens up action code.
Finally, youâll see int eh demo how I added an $OrigCreated attribute to capture the original created date. This reflects @mwraâs suggestion above.
Thanks, @satikusala and @mwra, for taking the time to provide in-depth answers. I will likely implement a combination of $MyCreated (@mwra) and changing $Container (@satikusala).
I see the logic there but I donât think it is a safe assumption. macOS may track file-scoped actions but dut/pasting a note inside an app is a different context. The user knows they cut a note in order to move a note elsewhere in the document but the host app doesnât get that human-only info so canât reasonably act on it. The disconnect bites if the scope of the cut/pasted data is a complete note. This was my point re untested assumptions, and wasnât meant judgmentally.
II think @satikusalaâs covered this above but to summarise, if you want to move a note, Tinderbox realistically has two options:
The âUIâ approach is drag/drop.
Programatically, set $Container, as I think has been addressed above.
I accept that the problem with setting container is that you canât do it easily in one step unless the target container is always the same.
Also, Iâm not sure thatâacross all usersâthe problem is as simple as figuring out if the note on the clipboard exists elsewhere. Why? A new not need a new unique ID (helpfully exposed as $ID). We canât assume cut and paste are a contiguous operation: the doorbell might ring, the plane might start decent to landing, etc. In that wider context, whatâs âobviousâ to a given human user is opaque to the app code.
But, if the above options (drag/drop/ or change $Container) donât suffice you could consider a feature request for what amounts to a âmove via cutâ feature. Iâm not sure quite how that would be defined, but admittedly mine is not the need!
Stumbled in here, trying to find information on how to move notes.
What I would actually want is being able to drag+drop across different tabs (click&hold â keyboard shortcut to switch tabs â drop).
As that seems to not be possible, I was looking at Copy â paste â go back & delete as the alternative. Is that really what users are doing? I feel like I am overlooking something (call for help ).
Towards the actual discussion here:
If such a feature should be requested, wouldnât it make sense to do it the way macOS Finder works:
you pick up via Cmd+C â no matter if you want to copy->paste or move
navigate to new location â Cmd+option+V will move the file there
That also should be enough distinction for the TBX software to âknowâ, that is should recreate the originals $Created value.
@midas0441 Did you ever reach out to eastgate to request this?
Yes, for Copy & Paste, I too would expect a new timestamp. But moving a file (Cmd+C â Cmd+Opt+V in macOS Finder) I would not expect a new timestamp. That is consistent with what happens in Finder. I would not support changing the current behaviour of Copy & Paste â I just wanted to point out, that there exists a solution for exactly what OP was asking for in Finder that could be made into a new âmoveâ feature for TBX.
In my case, the document is too big to comfortablyp drag+drop in Outline view. Iâd have to Expand view 4-5 times and then unfold multiple containers. Notes Iâm working with being far apart in terms of the outline structure is exactly the reason why I am working with multiple tabs â it allows me to quickly switch.
TIL: an Opt+paste changes a copy /paste to a cut/paste. Iâm used to using Opt+drag with tab-hover/tab select to move from one Finder tab to another.
Anyway, just because Tinderbox windows have tabs doesnât make me think theyâd work like Finder. They may look the same but are designed differently. Thatâs not a rebuke but simply pointing out using one as the model for the other isnât much help in figuring out the Tinderbox side of things.
I guess the normal Tinderbox way(s) are:
if the target location is in scope of the current tab, drag note to the new location (dragging near the edge of the view will cause it to scroll (at least in Map and Outline and likely Chart views).
if the target is not in scope, change the tab view type and/or scope so this does encompass source and target location. Change tab back when done.
(if comfortable with action code) move the note via action code, by setting the noteâs $Container: see more.
Iâm not suggest these are ârulesâ but just offering workably alternatives to your planned solution.
For copy paste, youâre making a new note so $Created, and more importantly $ID (the notes internal unique ID) will differ. Same if you duplicate a note, as the duplicate is a new note even if things like $Text or visual styling is the same.
As well as tabs, you canât drag between Windows. Also (for reasons I forget) all windows of a doc have the same $Text pane focus, even if the view pane types/scope differ (i.e. in some views the selected note may be out of scope). By comparison, tabs remember their own scope.
In context, it might be helpful to the general audience to note that making a new window replicates all the tabs of the current one, only the form tab of any widow is active. IOW, thereâs is no real overhead to those seeming extra tabs. So, if making a new window âjustâ to drag-move a note, any extra background tabs are immaterialâespecially if youâre gong to delete the new window once done.
Another little heads up for the general audience:
When dragging across windows it is not necessary to resize the windows to not overlap. Switching between the windows (via Cmd+ `) after starting the drag works. Iâm posting this here, because I first thought it does not work like that, but I only had to move the cursor on top of the target window for a little longer (like a second or so) before dropping.
).
