This kind of says it all:
I made a note that uses the built-in Markdown prototype. It looks fine.
I made it black. It looks fine, too.
In the natural order of things, it’s hard for me to tell you what you did, since I wasn’t there when you did it. But I notice there’s no dog-ear in the lower right-hand corner of your black note, which means that note has no text. That could happen because
- It never had text
- It had text, but you deleted it
- You assigned $Text to be empty in an action, rule, stamp, or edict
There’s probably some other ways to assign $Text that I’m forgetting, too!
I suppose that’s acceptable. But I think if you wanted to, you could totally get telemetry from every single Tbx user and cackle madly over your ungodly amount of data!
More seriously, this is very strange, is it not:
There’s definitely text there. I can confirm that I can create a new Markdown prototype from the Built-in and it works fine. I’m just trying to figure out what I did to this particular Prototype…I’ll attach a super small document for testing.
StrangePrototype.tbx (56.3 KB)
Took some spelunking but it’s the Shape setting. There’s a glitch, in that when you (re-)set the shape to ‘normal’ it sets a string value of ‘normal’ rather than no value, as would be expected. Correct that and text shows normally.
Bless you, sir, bless you!!! That was really driving me nuts.
@mwra I, too, am grateful for this. curious about how you go about tracking this down. I was trying to compare two notes, one with the prototype that caused the glitch (because of ‘normal’ shape) and one without, but found myself jumping back and forth between Get Info views. advice on a more systematic way to do a “diff” on the attributes of two notes in the case where difference could be in “any” attribute?
This case was unusual because it was a form of bug (app getting confused as to what ‘normal’ is) rather than an unexpected outcome. Don’t forget you can ‘tear off’ a Get Info pop-up so that it becomes a stand-alone dialog. Thus, you can easily open/view two or more Get Info dialogs. My process went link this:
- Check the main attribute controlling the feature in question - here
$MapBodyTextSizeand establish it works in other notes but not this one. Thus must be another interfering factor.
- Check if agents/rules/edicts are involved. The weren’t here, but otherwise I’d disable those process so further changes don’t occur - such as might ‘correct’ something you just fixed.
- Check other related attributes (colours, pattern, plot, etc.) in case these might have an effect (having 2 Get Info open - problem & a ‘good’ note - can help here). Obviously it helps to know what those attributes might be - this is just the sort of reference task for which aTbRef is intended.
- Here one such attribute was shape. When I set rectangle deliberately and saw it worked, that fingered $Shape as the likely cause. From there I was able to figure out that the Appearance Inspector was incorrectly setting a string value of normal, rather than no value at all (empty string) when ‘normal’ was selected in the pop-up.
Also, don’t overlook Outline + column view as this lets you see many note’s values for the same attribute in a single column. Even if working primarily in a Map tab, you can easily open an extra tab as an outline.
Does that help?
Very helpful. I will try the “tear off” for side by side comparison. really useful.
btw, now is a good time to mention how incredibly useful aTbRef is, not just as a reference for specific coding questions, but also as a way to pick up pointers. I am actually working my way through aTbRef bit by bit (leave web page open and read through a few pages every once in a while) and have discovered some very useful things that way. In fact, reading about the dog-ear indicator for body text got me looking at my Task prototype and wondering why I wasn’t seeing that, which motivated me to finally resolve the missing body text issue. Having a visual indicator of when there is text is incredibly useful and I wouldn’t have made the connection without aTbRef. Thank you!
My pleasure. The sort of use you describe is exactly why I publish the doc in HTML form. As long as you’re online, aTbRef is always to hand. You can of course get the source TBX, but its a busy doc and so more of a load to read in that form when trying to do your own work in Tinderbox. The TBX is useful for those who aren’t always online as it has everything (except the image - separate zip file) to run out your own local HTML that you can run from your hard drive.
BTW: a fix for the shape/text issue has been tested and should be in the next release when it comes. Until then, just remove the “normal” sting value if it gets added to $Shape.