How to use an agent to collect and change appearance of aliases without changing appearance of former originals

I am writing a novel. the chapters are in a container called Manuscripts. Each chapter note has user attributes of "draft’, “final”, and “latest”, among other user attributes. An agent in a different container collects all notes with “latest” = “true”. That works fine. I then have tried to change shape or badge of alias so i can identify, in the map view in Manuscripts container, the latest draft of a chapter by the agent-induced change in appearance. that works fine. BUT, when i decide to re-write a “latest” chapter by duplicating the note, say Chapter 5 original, creating Chapter 5 copy, and unchecking “latest” in Chapter 5 original, Chapter 5 original note retains the agent-induced appearance so that i can no longer see JUST the latest notes in the Manuscript container, which would be quite useful.

Is there a way to fix this with the agent or some other way? I have spent some time reading about attributes and designators of notes and aliases but am stuck.

thanks for any help from anyone.

thanks so much for interest and prompt offer to help

if i understand your request, here is answer:

Name of agent: latest agent
query: $latest=true
case sensitive is checked
action: $Shape=right tag

was that helpful? sorry if i got your question wrong. thanks again. basically what i want is to have a dynamic series of “latest” notes and aliases but only have current “latest” notes with the shape or appearance of the agent, not all former “latest” notes. i would want the previous, former “latest” notes revert to original appearance, i.e., the appearance of all notes NOT “latest”.

thanks again for interest.

I don’t know whether you’re familiar with the operator (original) in Tinderbox syntax. It lets you change traits of the original version of a note, but not of the aliases. The description in aTbRef is here.

Without being sure exactly what you’re trying to do, I imagine this would help you change the originals to a certain status – with a badge or a Boolean attribute or a color or whatever – while the aliases were unchanged. For instance you could have the action say:

$Color(original)=“blue” or $Latest(original)=false etc.

Perhaps this is the tool you’re looking for?

Is the problem that when you turn off $latest, the shape doesn’t revert back to the original shape?

That’s because your agent correctly changes the shape when it’s invoked – but you have no corresponding logic to turn the shape back when you untick $latest.

Possibly the easiest way is to have the logic in the prototype itself. You can still use the agent to collect the latest notes, but leave the attribute toggling to the prototype.

E.g. have a rule something like this in the Rule panel of your prototype:

if($latest==true){$Shape="right tag"} else {$Shape="left tag"}

That means that whenever you change the state of $latest, the shape changes accordingly.

Yes, this logic – if / else – applied in a rule might also be exactly the tool @howie4 is looking for.

Thinking about it…

A simpler answer would be to have an entry in the agent’s Remove panel

$Shape="left tag"

This will reset shape when the agent is exited (ie $latest is turned off).

Yes, good point.

Meta-theme as intro to Tinderbox: it’s an illustration of the many possible paths usually open to any given destination.

Remove is a first cousin to if /else – each of them applies an action as long as certain conditions are met, and then applies a different action when the conditions no longer apply. (This is different from a normal agent, which applies a result – let’s say $Badge=“check”– if a condition is true, but then doesn’t care what happens if the condition is no longer true.)

Similarly, you can say that Rules are cousins to Agents are cousins to Stamps are cousins to Smart Adornments, each of them applying a “logical test → resulting action” sequence, but offering fine-tuning details in how exactly they work, and when. The meta-point is that beneath the apparent vast complexity of the program is a finite number of test->result operations, and once you’ve tried them in a variety of circumstances, you have a guess of which one is most convenient for which circumstance.

Well put.

TBH, I’d not actually got round to using $OnRemove… knew it was there, but just carried on the old ways without thinking about when I could apply it. Took answering a question to think ‘of course…’

I bet there are loads of things like that…

THANKS!! it works like a charm! i thought of a rule like that but to be honest, i am not real good at Tbx and would have put it in Mss container AND would not have figured out by myself the “else” logic. your rule, in prototype, works wonderfully and is exactly what i wanted for easy identification of where i left off in my drafts of a “latest” chapter before i change it to “final”.

thanks so much. it is really gratifying to see the generosity of a community like this. i have gotten 6 or 7 replies from 3 different people in hours.

thanks to all!!

1 Like

i should have mentioned that i am using Tbx 5.6 for various reasons. i have no idea what “the agent’s Remove panel” means. am i not finding it or is this a post-5.6 feature. with my primordial needs i find 5.6 sufficient although i must admit the attribute browser view looks yummy.
thanks again for your help!

thanks for all your help. as i noted in previous reply, i have no idea what REMOVE is.
but i am very grateful for all the support, and promptly so, i have received.

1 Like

FWIW, the current version is an entirely different thing from the TB 5.6 of several years ago. And 99% in a good way. That’s where you’ll find the Remove command, and above all the Attribute Browser, which is a program in itself. Also aesthetically more elegant, and faster.

We all have different needs and imperatives, but to me the upgrade is very much worth it.