Tinderbox's host OS is case-sensitive as is the app in the majority of cases. Notable exceptions are export codes and agent query special arguments. In both cases there is a general TB usage convention to intercapitalise such words with a lower case start and capitals at concatenated word boundaries. Inter-capitalisation helps distinguish different Tinderbox code types.
Conversely, attributes are case-sensitive: IsInside, Isinside, isInside and isinside would all be treated as different attributes by Tinderbox if forced to guess. Of the four styling the first is recommended, the second less so and the last two are deprecated to avoid user or app confusion as to purpose when using in code.
To help illustrate this, consider a fictional 'insideness' state—'is inside'—as expressed through the major code types, noting that:
- ^isInside(arg)^. An export code: inter-capitalised plus the carets indicate this is export code. (This is also a real export code). Export codes are case-insensitive.
- IsInside. An attribute: opening capital plus inter-capitalisation. The styling of the words would also tend to imply in Tinderbox usage that this would be a Boolean type,
true/false
attribute. (This is not a real system attribute). Attributes are case-sensitive. - isinside(arg). An action operator, all lowercase. This would likely be the internal analogue of ^isInside^, though the case insensitivity of the later codes means export and action codes tend not to share a name. (This is not a real action operator). Action codes are case-sensitive.
- Deprecated/defunct:
- #isInside(arg). A special query argument. The opening hash characters is a give-away plus inter-capitalised styling. Note: this is not a real argument, though #inside(arg) does this function. (#codes are deprecated since v4.6 for action codes). Old #codes were case-insensitive; new query codes, being action code, are case-sensitive.
As Attribute and Action codes are case-sensitive it is a good working model to pretend Export codes are also case-sensitive, and thus stick to a consistent case for the latterTbRef follows this model using lowercase with uppercase letter for word boundaries, as in '^ descendedfrom^'.
Other areas where case sensitivity has an impact are in searching (queries & find dialog) and sorting (containers). By default:
- new (agent) queries are case-insensitive but that state can be toggled by a tick-box on the agent's Action Inspector's Query sub-tab and via the AgentCaseSensitive attribute.
- the Find dialog opens with case-sensitivity set 'on' but this can be toggled via a tick-box on the dialog.
- containers sort case-sensitively by default, i.e. letters sort by character number with A-Z sorting before a-z. Container sort has controls both via note/agent Action Inspector's Sort sub-tab and via the Sorting group of system attributes.
Sorting is discussed in more detail separately.
See also—notes linking to here: