Cut/copy and paste changes $Created

[midas0441 (aa)]

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

$Created time of copied notes

Hi all, If I copy and paste a note, the newly created note will have its $Created attribute set to the creation time of the old note. It seems to me that $Created should indicate when this note was created. Do other folks agree?

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.)

[mwra (Mark Anderson)]

@midas0441

Any suggestions on how to paste while preserving $Created?

$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.

HTH, and if not, do ask.

[midas0441 (aa)]

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.

[satikusala (Michael Becker)]

@midas0441

More probable is that the note is being moved.

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.

1. 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.

2. 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.

3. 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.

See attached.

TBX L - Copy Container and Move Notes.tbx (81.1 KB)

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.

[midas0441 (aa)]

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).

[mwra (Mark Anderson)]

@midas0441

If macOS kept track of whether an item in clipboard was cut or copied, one could could tailor paste-action.

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!

HTH