Tinderbox Forum

Confusion about user attributes and prototypes

It’s been about six years since I last had a Mac and could use Tinderbox, and I’m slowly re-building my knowledge. One thing I’m confused about is the use of user created attributes and prototypes.
I took the basic action prototype and tried to create two new user attributes: projectName and contextName. I struggled for awhile as I seemed to be only able to enter either. But I finally got them both created (it’s confusing because I created the attributes in the user tab of the document inspector but there was no way to “create” or say done. But somehow they both started showing up in the + button for the prototype note for action and I successfully added them.
I thought merely adding these new attributes would alter all my existing tasks to add the two new values, but only one value seemed to be being added to these notes until I reset them. New action prototyped notes seem to have them both.
Sorry if this isn’t clear, I’m still remembering the basics. Can anyone shed any light?

Actually it is a bit confusing as It’s not too clear what you’re doing - apart from not getting what you want. A few suggestions though:

Add a ‘Prototypes’ container. The easiest way to do this is to add any of the built-in (i.e predefined) prototypes from the File menu. The point is to get Tinderbox to add the container - you can delete the prototype you just added if not of use. Now, any note you add to the container will be automatically set as a prototype.

Adding new User attributes. When you add a new user attribute via the Document Inspector/User tab, use the gear-wheel button, select ‘New User Attribute’, type the attribute name and click the Return key to finish the edit. If you’ve typed an illegal name (or re-sued an existing one) the text in the name box will go red. After giving the attribute a name you can set other things like the data type - pop-up controls commit when they lose focus, in input boxes click the return key to commit the change.

Adding new attributes via KAs. An easier way to add new attributes on the fly - especially if using them as Key Attributes, is to use the plus button top right of the text pane to open the Add Key Attributes pop-over. Add the name of the new attribute and on closing the pop-over you’ll be asked if you want to add new attributes. Note that besides a name you can only set the data type via this method but it’s very handy. You can always tweak less common setting via the inspector later.

More detail please as to what you did. Are you talking about the attribute’s values or the new attributes being used as Key Attributes. I suspect you’ve omitted to allow for inheritance issues but without more detail it’s hard to say. Can you perhaps give us the steps to recreate your problem (don’t assume any steps don’t need mentioning as too obvious).

1 Like

@mwra’s answer is right on as usual.

I almost never use the document inspector to create new attributes — I use it to change attribute names, delete user attributes, and set default values.

As @mwra suggests, just add the attribute as a key attribute and you will be prompted to create the new attribute when you close the Add Key Attributes popover.

When an attribute has a local value, which has been set by hand (or action code) rather than inherited (and indicated by that attribute being displayed in bold in the Key Attributes list and the Get Info panel), changing the attribute’s value in that note’s prototype will not change the locally set attribute.

Most likely you had added some key attributes to these existing task notes by hand. This would cause the KeyAttributes attribute of these notes to have locally set values, so adding key attributes to their prototype would not affect their KeyAttributes value. To get them to use the Key Attributes of their prototype, you would need to reset their KeyAttributes attribute to its inherited value.

This is such a common occurrence that I have a stamp in my default TBX starter document that does this:

I use it all the time.

I think what I’m missing is understanding key attributes, aside from what appear to be basic mac ignorance I’m displaying. I’m going to dig in based on your generous attempt to answer my confusing post. Thanks.

At it’s core Key Attributes (KA) is a list of attributes that a note should display in its text pane. That list is stored in $KeyAttributes. So, if you set up a prototype’s Key Attributes, all notes using that prototype will inherit the same KA listing. Unless of course you change the KA list in one of the inheriting notes as that breaks the inheritance of that attribute. The prototype’s KA values are also inherited unless:

  • You edit that attribute at note level. (Tip, if so, that attribute is listed in bold)
  • The attribute is intrinsic.

You can also customise the look and feel of KAs. See more: here and here.