Good morning. What is the significance of the red line? Thanks.
The red strikethrough and other styling of Displayed Attributes is described here.
As to $OutlineTextSize, it is deprecated and thus struck through. Deprecated attributes are not arbitrarily removed a user may have a use for them or possibly be using an older version of Tinderbox where that attribute is still used.
Iāve edited the title of the thread to reflect better its subject
Thanks very much, Iāll check the link.
-CB
Oh, the disable autohide was a question I had earlier. When I posed this new one, I just amended the old draft, but forgot to update the title. Apologies for the confused post!
1 Like
As a follow up question: once Iāve assigned a value to a deprecated attribute, how do I undo that? Is it by assigning the attribute its default value? Thanks in advanceā¦ I may have missed the answer somewhereā¦
It doesnāt really do any harm, so you can just leave it. Or, click on the Displayed Attributes (or in Get Info) table with the attribute to reset, right-click on the row of interest and use the āUse Inherited Valueā option in the pop-up menu. More reset options are listed in article Displayed Attributes table, section āResetting default/inherited valuesā.
Deprecated Attributes
Deprecated attributes generally fall into one of these categories:
- Redundant, as the feature no longer exists (in current version). So, $ShowTitle pertains to the pre-v6 design and now does nothing. It is not part of current new TBX system attributes but may be found in TBXs generated by pre-v6 app versions.
- Feature was renamed. Thus in v8.8.0 āKey Attributesā (and all attributes using that term (e.g. $KeyAttributeFont) became āDisplayed Attributesā. In the case of Key Attributes, these older variants are still added to a new doc, but more often, older name variants are dropped for the system attributes of new TBXs.
- Name case changes, a rare subset of the above. After launch of an attribute a more idiomatic spelling is chosen, so $Wordcount became $WordCount.
Values in Deprecated Attributes
Note: users canāt delete system attributesāat least not via the appās UI.
So, discontinued featuresā attributes are best ignored. Unless they hold a vast amount of data per note (which is unlikely!) you can consider resetting the attribute values (as described above).
If you are using a deprecated but working attribute (e.g. $KeyAttributes vs. $DisplayedAttributes), I would suggest copying the āoldā attributeās value to its replacement and resetting the old attribute and not using the latter again.
Deprecated Attributes in code
This will most likely occur in action code (but donāt overlook agent queries or export code, e.g. in templates.)
It is quite easy to locate old attributes in action code with this agent query:
$Rule.contains("KeyAttributes")
will find all notes with rules using $KeyAttributes. But if you use prototypes a lot, likely your rules, edicts etc. are inherited, so it is strongly advised to filter first for prototypes:
$IsProtoType&$Rule.contains("KeyAttributes")
This avoids editing prototype-inherited code and thus breaking the inheritance.
The attributes to check for action code or query use are listed under Action code related attributes.
Checking $Text will cover Stamps, (Library) Functions and Export templates, boilerplate and code-storage notes. You may get a few false but these will be self evident.
The only place you cannot check via a query is the Export Macro listing, where you will need to use the Macro Inspector.
Tinderbox legacy support
The Tinderbox app is now 23 years old and has seen a lot of gentle incremental change. One effect has been the group of redundant attributes. But, at most points of change, documents might have to be used in both old and new app versions without breaking in either use. The same holds for actions/export code.
Eastgate is thus generous to the user, in terms of avoiding sudden and hard to guess (for the occasional user) failures of attributes/code that used to work. Not least because some, especially occasional users who donāt want to have to learn new things, wish their existing docs to work unchanged.
The flip-side of this generosity is reflected in the way there is often a simpler way to a task, e.g.
Color2 = blue
This works but is not recommended as best practice:
$AccentColor = "blue";
Because:
- $Color2 is deprecated in favour of the more self-explanatory name $AccentColor.
- string values are generally set in quotes.
- an expression (or end of code line) terminator is not needed for a single expression, but good muscle memory for when multiple expressions are used in an action. Multiple codes on different lines but without terminators will failāsilently.
So why the latter change? Isnāt this just pedantry, if the former works? Not so, the old example is very simple, a more complex code in that form would likely fail. Originally, Action Code was, like AppleScript, written simply and the parser would guess. As Action code became a lot more capable (of far more complex tasks), this taxes what the code parser can āguessā as to the user intent. So, the latter more verbose form is more declarative and makes it less prone to confusing the code parser. the latter happens very infrequently, but you only need to trip up once to realise that using the latter form is enlightened self-interest.
Sorry for the long answer above but I realised Iām essentially drafting a new aTbRef article - to save having to write this again in a future forum answer 
. If there are any aspects of this I havenāt covered or which are unclear, do pleaseāanyone reading thisāsay so, as that will feed into the eventual article.
BTW, if you mess up cleaning up references to old attributes in action code attributes (rules, etc.) by editing code in prototype-using note rather than in the prototype, this too is easily fixed.
Create a query that finds all notes using that prototype, e.g. for prototype āXā:
$Prototype=="X"
and then an agent action to re-set all those notesā rules, edicts and OnAdd actions:
$Rule=;
$Edict=;
$OnAdd=:
This =; usage resets to noteās attribute to the attribute doc default, expect for notes using a prototype in which case the doc default is replaced by the prototypeās value for this attribute.
An edge case occurs for intrinsic attributes: those where an original note and its aliases can have discrete values, e.g. $Width. In an agent, the action is run on an alias so the action needs a small modification:
$Width(original)=;
If you donāt have to worry about whether the target attribute is intrinsic or note, you can use the latter form for non-intrinsic attributes without harm:
$Rule(original)=;
Great, thanks for the detailed and fast answers!
1 Like