I have been making sure to have unique names for similar notes by adding unique words to the end of a $Name. For example: say I have two notes with $Name “I did this today Trial 11” and “I did this today Trial 10.” (No quotes in actual $Name.) Most of the time, this works fine.
Today, using those hypothetical notes, the “I did this today Trial 11” note looks fine in the text pane, but when the preview pane is clicked, Tinderbox finds and moves its focus to the note “I did this today Trial 10.”
I have no idea why this particular note has an issue and not other notes that follow the same naming convention.
An easy fix may be to change my naming methodology to start with something unique instead of ending with something unique. That’s the solution that fixed my current issue.
Another fix may be to write whatever I want as a Title $DisplayExpression and then run something like $Name = $SomeDistinguishingNoteAttribute + $DisplayExpresson.
Are there more elegant ways to ensure that Previews don’t get confused by $Names that start with duplicate text?
Hi, @_Bill . OK, so you’re clicking the Text pane’s sub-tab from Text to Preview and the view pane is changing the selected note? The text pane as a whole, regardless of tab selected, shows data for the note selected in the view pane. For the preview to show a different note (e.g. following a link in the preview) in preview, you should see the View pane alter its selection. That seems to be what you report.
Are the two notes linked? What template is in use?
If you have a small TBX that shows the effect repeatably it might help. I see what you’ve written, but can’t see how why that is occurring. Before re-jigging all your naming and possibly making a masking error, it would be good to get to the bottom of this.
Bear in mind—and apologies if you understand this already—note links to the $Name (actually $Path, and way under the hood, $ID) of the note, so $DisplayName (as effected by $DisplayExpression) does not necessarily the title of the note being linked to.
Still, merely entering preview mode ought not to trigger a link traversal or view [sic] selection shift.
I Bill, I"m not sure if this helps, but as you know, my solution to helping with naming collision is to use a prefix, rather than a suffix. Why? The prefix is easier to save in the outline and in Mapview to distinguish between different notes. It is better for searching and, most certainly, better for parsing. It is also better for handling nuanced searches.
Do you have a pattern for your note names? Is the use of a number important? Do certain not that have the same, have a similar type, e.g., “note,” book," “figure,” activity?
Understanding the context may help us guide you to a more efficient approach.
Aliso, I have seen this behavior a ton when $HTMLExportFileName is the same. Typically, $HTMLExportFileName will use $Name, but if you have any action code that has changed this, then Tinderbox will get confused and will display the first note in the outline order with the same.
Aha, that may be due to having an old and shorter default size for $HTMLFileNameMaxLength or using very long $name values. The current $HTMLFileNameMaxLength default is 100 but this only changed from 24 in v9.5.0. If not in a new TBX, go to the system attribute Inspector for $HTMLFileNameMaxLength and set it to 100. That ought to cover most cases.
Tinderbox does, IIRC, give discrete names if two (complete!) notes’ $Name in the same container are the same. But if the $Name length exceeds $HTMLFileNameMaxLength then there is no way for Tinderbox to know. These days people use longer note names and HTML is less likely to break on longer file names.
Why is this occurring. The preview is using an HTML-exported version of the doc so whilst it appears to be all internal, effects like name collision of exported names.
If @_Bill 's doc has the old default of 24 characters, i.e. it was created in version before v9.5.0, that would likely account for the effect @satikusala mentions.
TL:DR as well as prefixes vs suffixes, consider $HTMLFileNameMaxLength. It’s a matter of taste, but suffixes can make thinks harder to read as the bit the human eye/brain needs it pushed off out of the visibly displayed bit of the name. so there is no one right way: consider your context and needs.
Mark and Michael, thank you for that discussion, which teased out the solution and provided insights about prefixes, suffixes, searches, and HTML system attributes along the way:
Voilà!! All works well… until the next time I break something.
