Setting an absolute path as an attribute

Hello all. I am marking some notes as a priority (flag yellow) and urgent (flag red) and using an agent to group them for me. However I would like to know the original location of the note and not the alias when I look into the agent container. Can I set or make an attribute that does something like $Path(Original) so it always shows the original and not the alias? Thanks in advance.

Youā€™re almost there: you want

$Path(original)

with a lower-case ā€œoā€. (All designators are lower-case: this, parent, previousSibling, nextSibling, etc.)

Further to the previous answer, see descriptions of designators, of which item-scoped ones are likely mrst of use here.

Thanks. I am trying to make this an attribute to be displayed but it seems to just display the code - $Path(original) - how can I get it to display the actual path of the note? Thanks again.

Can you please show the code you are using to set this value and say where (Inspector, Get Info, Displayed Attributes, etc.) you are setting it.?

My understanding is that you want every (or all relevant notes) to store their originalā€™s $Path in a non-intrinsic attribute ($Path is intrinsic). So Iā€™d make a String-type attribute ā€˜OriginalPathā€™ and add it to the noteā€™s Displayed Attributes. Then iā€™d add an edict (you donā€™t want this running all the time):

if($IsAlias==false){$OriginalPath=$Path);};

The ā€˜ifā€™ is because aliases also execute the same rule & edict code as their original, and we only want this to run in non-alias (i.e. original) notes.

Thanks for all the help and pointers! I was just wanting to set all notes to display the path attribute by default (using DisplayedAttributes) AND also wanted the Path attribute to display the absolute path and not the alias always --> like $Path(original).

1 Like

Great. Have the answers above solved the issue?

There is no ā€˜absolute pathā€™ in the way you describe it. The $Path for the alias is it absolute path. It is worth reading up on intrinsic attributes. The alias has to have its own path as it resides in a different part of the application.

What you access via $Path(original) is better described (for fellow users here) as the ā€œoriginalā€™s pathā€ (ā€œoriginalā€™s $Pathā€). The latter follows the shorthand convention here of indicating a textual reference to an attribute nameā€”as opposed to literal use of that word/titleā€”outside code samples by using a $Prefix.

Thanks Mark for the clarification and help. I will review what you posted earlier, in-depth about intrinsic attributes.

1 Like

Thanks. By all means post again if stuck. Intrinsic attributes and designators can seem a bit alien at first sight, but they are pretty simple.

This is a list of known intrinsic system attributes (as indicated by the XML source of TBX documents). Quite why $Path isnā€™t there listed Iā€™m not sure but will follow up directly with Eastgate, as it behaves in an intrisic manner.

Adding to this thread, is there an easy way to delete an original from alias results? I realize that you can go to the original by rt mouse-clicking, but this takes steps. I donā€™tā€™ see a menu item for this and canā€™t figure out how to do this with a stamp.

OK, first a WARNING. delete() is something to test before using in a working doc and keep back-up: this feature has no ā€˜undoā€™.

You could use delete():

delete($Path(original));

N.B. Iā€™ve not tried it (late here) but it should work. Iā€™d not automate it, but if the code works it might work well as a stamp.

Hello Mark thanks again. Writing it this way seems to have worked for me: if($IsAlias==false){$OriginalPath=$Path};if($IsAlias==true){$OriginalPath=$Path(original)}

I also put this as default under edict attribute (Document Inspector>General) so it covers everything inside the tinderbox doc/file. Is this the proper place to put it if I want it to be global or should I put this somewhere else?

Iā€™m glad that works. It can be written more simply as:

if($IsAlias==false){$OriginalPath=$Path}else{$OriginalPath=$Path(original)}

Note that $OriginalPath is not intrinsic so only needs setting once from either an alias or the original.

BTW, Scott, would you mind providing some detail around the purpose of this need. What benefit will knowing this give you? Iā€™m trying to get insight for one of my next videos.

Sure no problem. I have 3 agents running at the doc root called ā€œUrgentā€, ā€œPriorityā€, and ā€œThinking about.ā€ That allows a top level view of any pressing issues I have (or my thoughts or concerns that are pressing). But I also have a hierarchy of nested containers and notes. When a note is urgent but is nested within a hierarchy for example and I want it front and center: I give it a badge ā€œflag redā€ and the agent ā€œUrgentā€ search for it and pulls it ($Badge=="flag red";).

So this edict that runs on every note if($IsAlias==false){$OriginalPath=$Path};if($IsAlias==true){$OriginalPath=$Path(original)} then labels the notes with their original paths so when I look into the agents on the top level (ā€œUrgentā€ ,ā€œPriorityā€, ā€œThinking aboutā€) they give me their original location path of the note which in turn lets me know the context/subject matter it is related to therefore providing meaning - I could not get this from using the aliasā€™s path. Hope this helps.

Sorry also I turn the (user attribute) ā€œOriginalPathā€ attribute on in DisplayedAttributes so it shows up in every note.

1 Like

The interesting meta-reflection for me, reading the last is we differ in our mental approach. My own immediate reaction reading this is ā€œwhy would you not know where the original isā€ but Iā€™m reminded we conceptualise in different ways.

That said, I have to ask what this means

What does the original tell you that the alias doesnā€™t? context: start from the assumption we donā€™t know know the view type of container-scope if the view you have in mind.

As most attributes are non-intrinsic, what does the differing context supply.

I ask as I sense you may be solving the ā€˜wrongā€™ problem with this approach. IOW, there may be an easier solution if we understood the real underlying question.

I had the same reaction. To Markā€™s point RE different approaches on conceptualization, here is my immediate thoughts.

You appear to be looking for context from the outline structure. If the note were to move, does this change the context of the note, or would this action simply put the not in a different container while retaining its context?

If the later, then driving context from the outline could be dangerous if notes actually move.

For a note to retain context you could create various attributes that retain the context. For example, I always apply a $Type attribute to every note, that way I know what kind of note the note is, person, event, theory, article, etc. That way, if I accidentally break or delete a prototype, Person for example, I can simply run an agent on all notes with $Type=ā€œPersonā€ and reapply or apply a new prototype. So, $Type is an important context form me.

You could do something similar with other attributes, e.g. $Theme, $Category, $Effort, etc. Youā€™d effectively be moving your context from outline position to attributes. In my thinking, this creates a lot more flexibility and mobility for your notes. It will allow for transformations as well as the ability to migrate notes between Tinderbox files, without losing context.

Hello Mark, hopefully these pictures will help explain some of this. I wanted a common area for my urgent and pressing stuff but without changing location of the note (location of the note as meaning for me). So for example I could look into the Priority agent and see what needs attention. And then I could look at the OriginalPath attribute and it tells me it original location. This is a simple example, some of my notes are more nested than this and that OriginalPath becomes more helpful. NOTE: I purchased Tinderbox 10days ago and been using it for 2wks so I am ā€œin process,ā€ but reading the manuals which have been helpful. Thanks for all the input and advice.

Hello Michael, thanks for your input and pointers. Also I viewed most of your YouTube videos about Tinderbox and it was very helpful. Please see my reply to Markā€™s post it has pics and an explanation about why I set it up this way.

Your Attribute vs location makes a lot of sense - I will need to think about structure and design. I just started using Tinderbox and its flexibility is still surprising to me (all the possibilities). Thanks again for the help.

1 Like

Thanks. That makes sense in context. Given your approach of location within the outline having meaning (which is perfectly valid!) sing a noteā€™s location from the aliasā€™ Displayed Attributes makes much sense.

Your if/else approach of setting the stored path from both original and alias via edict should be pretty robust to the original moving. Plus, in the latter case youā€™ve only to run the edict on demand from the Action Inspector, Edict tab to ensure all is updated. Or, by using File menu ā†’Update Now, all Edicts are run once.