Please let me know if I should create a new post or continue asking question here.
I’d like to create a new Note Type : Phone call where I can note down when (date) and to whom(person) I made the call to and the content of the call.
How do I set above (attributes correct?) to a given note quickly ?
I think prototypes† is the way to go, as likely you’ll have many such notes. But whether you first a prototype or not setting a notes Displayed Attributes, seen as a notes Displayed Attributes table in the text pane, is pretty simple.
†. If using prototypes also read up on attribute inheritance if new to this in Tinderbox.
With the new note (or its prototype) selected open the Add Displayed Attributes pop-over and use that to select the attributes you need. If you need attributes not yet configured you can type in the name of the as-yet unmade attributes and when you close the pop-over, you’ll see an additional pop-up and be asked if you want to make those attributes and set their data type‡. alternatively, you can set up you new attributes first, in the Inspector.
‡. If you need to customise the attribute beyond just the data type, e.g. to give it a specific default value, then you will need to use the User attribute Inspector.
Thus, I’d make a new prototype “pPhoneCall” (Tip: use prototype names that stand out from 'normal ’ note names). I’d give it the Displayed Attributes $StartDate (for the date of the call), $DueDate (in case there are follow-ups) and a new Set-type user attribute $Callers (as there may more than two people on the call). We don’t need a n attribute fro the contents of the call as that is better put in the $Text. I’ve made an example: new prototype example.tbx (80.9 KB)
which looks like this:
For the demo, I added a ‘Calls’ container, whose $OnAdd action I set to $Prototype="pPhoneCall";. That ensures all new child notes created in that container automatically set the ‘pPhoneCall’ prototype and thus inherit the prototype’s Displayed Attributes, badge, etc.
The benefit here is that you’ll likely have lots of call notes. If they all use a prototype and you realise call notes need a new Displayed Attributes item, you simply update the prototypes instead of having to manually edit each call note.
Lastly, don’t be bound by the choices I used for Displayed Attributes in the demo file. This is for your workflow and to record the nature of your calls. Customise as you se fit. Tinderbox is very supportive of incremental formalisation, so don’t sweat getting all the Displayed Attributes right on day one; I’ve already described how simple it is to add Displayed Attributes and how prototypes make this easy at scale. For instance, you might want to add the $Tags attribute to capture thematic keywords relating to the call. Adding that to the Displayed Attributes will populate the item into the Displayed Attributes table though of course you will need to review the notes and set the desired tag values.
WOW
Thank you for such detailed reply . It was such a breeze to follow the instructions, not only did I understand
Question
How do I edit the property of an attribute once it’s been created? For example once we created $callers , maybe I want to edit it’s type later on?
You can change the Type of a User Attribute ( but not a System Attribute) in the Document Inspector.
BUT BE CAREFUL – you might change a String attribute to a Number and make problems for Agents or Stamps or whatever.
It is best to change Type on an attribute before you use the attribute extensively in a document.
Further to the last, attribute names are case-sensitive. Thus ‘Callers’, ‘callers’, ‘CALLERS’, etc., are all different attribute names from Tinderbox’s perspective I’d go with Tinderbox’s attribute naming conventions as it means most code examples you see will make more sense.
For user attributes you can change the case of an existing attribute, e.g. ‘calls’ to ‘Calls’ but you will need to update any actions and queries that use the old name. Another good reason you internalise the attribute name conventions early on.
Whoa !! Document Inspector Fabulous , Thanks @PaulWalters for showcasing this to me. I saw the menu and ignored it multiple times , great to know I can change attribute settings from here
@mwra, CASE-SENSITIVE attributes ! honestly I could have never guessed this. Thank you again for writing about this.
Me trying to read TB reference file
Note to Self
Document Inspector (trigger by Cmd+2) is different from Document Settings ! DUH !!
More precisely, Cmd+2 opens closes the Quickstamp(i.e. the Propetties Inspector at its quickstamp tab.
Cmd+1 toggles the Inspector on/off. At the beginning of the app session (i.e. when the app is (re-)opened) this opens the Appearance Inspector at the interior tab. For the remained of the session the Inspector remembers the last selected tab when closed and re-opened.
The reason for this apparent duplication is that for over 14 years the above were separate dialogs, until the v6 code re-write.
Cmd+8 opens the Document Settings dialog with is the rump of the old Document-level preferences. The old preferences were massively thinned out during the re-design for v6.
The easiest way to check other shortcuts (beyond opening menus) is to look at a reverse look-up list.
