(first, congratulations on the new ATbRef, which alerted me to congratulate the new Tinderbox 9.6!)
Say, for example, I’m writing some code for a stamp action that would take the timeline start and end dates, and map them into aliased notes’ x and width properties; it would need to know the container’s start and end dates, to properly map the positions.
It would make sense to build this as a more generisable solution. I note that the container note for a timeline view doesn’t assume that StartDate and EndDate may not be the attributes that child notes may use to specify dates, and that there are TimelineStartAttribute and TimelineEndAttribute properties provided to define which attributes child notes expose their dateyness through.
I know in action code the convention is $Attributename() to access the properties of attributes of a note; but how would this be expressed if the attribute being accessed is not known in advance, and is stored in a variable?
Without testing, I’d be guessing at something along the lines of &$myattributenamestring() but that feels horribly wrong; what’s the correct way of handling this? (tl:dr; if I get $TimelineStartAttribute of a note as a string, how do I use this string to access the matching named property of other notes in code?)
Let me check I’ve understood. I think you asking how to make a valid attribute reference, e.g. $SomeDate where the ‘SomeDate’ part is actually a variable’s value. The most common scenario is where you have a list (List or Set) of attribute names you wish to turn into references such as:
You have understood perfectly and pointed me at exactly the function I need, which is action(). Thanks @mwra!
I missed that one when hunting through your ATbRef - I was expecting something dereference-ey or attribute-y or a more classical get()/[] structure … looking forward to that fully-native JavaScript in TB10! (ducks)
That’s definitely a term I never use as being too programming-based for a general lay audience. No judgement there, but pragmatism about ease of comprehension. But as your point shows, I’m ever proved wrong.
In context, from v9.6.0, [ ] for defining lists (and sets) and {} for defining dictionaries are now thr preferred method. That said, it’s pushing against 20+ years of documentation/demos/tutorials and muscle memory. Also Lists != Arrays and Dictionaries != Objects. Similar but different, which is an important if inconvenient fact.
Action code’s getting easier to use but perhaps, for many, harder to learn. More documentation then…
(ducks)