I’ve watched what @satikusala demonstrated last Saturday on the video, and I’ve tried to replicate it in a small test file. I’m ignoring the CSS piece to make things as simple as possible, and I have just changed the code in HTML item
When I view the Preview/Export panes, the export seems to default to H3 for all notes of $OutlineDepth 2 or greater, when $Outline depth 2 should be H2.
The relevant portion of the recorded video begins at 1hr. 20min.
Not necessarily the cause of the main problem, but one obvious error is using ‘=’ (assign a value) in a query when trying to set equality of two terms, i.e. ‘==’. IOW, that line should be:
^if ($0utlineDepth=="2")^
Using the correct syntax is a query matters. It might be hard to remember first time but as the usage is documented (links above) check the documentation each time until you are confident you’ve learned the syntax.
As 0utlineDepth is, I believe a valid attribute name, Tinderbox can’t tell that the reference is a typo for OutlineDepth as opposed to referring to a not-yet-defined user attribute called 0utlineDepth.
I picked up on 0utlineDepth beginning with a zero right away, thanks to my ancient FORTRAN reflexes. This is the sort of error that’s truly hard to catch!
Well, it appears that I have outsmarted myself once again. Rather than try and type the code in from the video frame, and make a typographical error, I used TextSniper and converted the screencap into text.
I thought I did look at it closely, but I missed the zero entirely, I’ll need to pick a font that uses a slashed zero. I don’t know if Textsniper inserted the extra space after ^children, that may have been me as I fumbled around trying various configurations, adding and subtracting spaces between various elements.
I did try the “==” in the obviously defective code, so naturally that didn’t seem to make a difference. I also recalled the “=” for assignment “==” for comparison discussion I heard someplace; but I think if you look at the video at 1:22:27, there’s just single “=” and it seemed to work fine. So either I need a new prescription or that “==” isn’t essential in export code. But I’ll stick with it in comparisons, just to be consistent between export code and action code.
The zero is what got me. Probably would have worked right the first time. I think the extra space is something I did.
Yes, that’s due to legacy support for very old code where = was allowed in a query, and thus my note that it likely wasn’t the cause.
Given all your attention to detail it seems TextSniper may well have been the innocent cause of the stray extra spaces inserted in commands. there, it will be trying to make readable sense of the scanned text. In that context, script/code is very typical writing. Tinderbox may have coped with extra space—but it’s best not to rely on that.
The mis-named attribute seems the root cause here, but it’s useful to see how innocently some of the errors crept in, e.g. OCR-type software misunderstanding code as parsing with normal written English conventions.
Amen. As pre-digital Navy signals guy I still find myself reflexively using a crossing bar on zero (0 vs O), 7 (7 vs. 1) and Z (vertical bar for Z vs 2); working at speed under minimal red lighting clarity trumps aesthetics (this may ring a bell for some readers ). So, oddly, I didn’t gat quite the same prompt, even on opening the template. Why? Aesthetics. The font designer of the font (here Andale Mono) chose to reassert aesthetics and replace the zero-with-diagonal-bar (a normal zero with cross-strike) with a dot on the middle of the character.
No foul there though, as IIRC Andale Mono was designed for aiding machine OCR rather than human character recognition. But it does explain why just changing the ‘normal’ style of cross-strike zero failed to register as quickly as it did for Mark.
If anyone is still reading, one more tip, from experience. If the code isn’t working, but you’ve confidence it should (e.g. you’ve used the same commands elsewhere) and it is still failing, try re-typing the code from scratch. Ideally don’t touch-type whilst reading from the existing code. The trick works because, for instance, whereas the eye might read if (… and see no issue when typing an if() from memory you are unlike to insert an unwanted space. Old-style human hack that’s got me out of the pickle in the past. Odd how our (proof)reading skills are nerfed when screen reading. I mis miss errors on screen that I never do if reading the same text printed on paper.
[Edit: necessary post-edit correction in last line above proves my point. Only spotted that re-reading the article later on].
True, this is useful technique† but actually solves a different issue.
However, the intent here isthat everything 2 levels down or more from the top exported note will use an <h3> for its heading. Therefore ^value($OutlineDepth)^ would be wrong for outline levels 4+.
†. IIRC, I think I first posted that approach back in Tinderbox v5 days, for exporting outlines. Seems like yesterday, though actually not.
When trying to figure out a tricky template, it’s useful to compare the HTML that’s being exported (see the HTML pane) with what you wanted to export. That way, we know what didn’t work, and can figure out how to fix it.
I can’t test (no test document offered) but I’d wager you’ve set the dictionary in a single note and then assuming the template knows where to find it.
thanks for your help - I added the attribute to the HTML item template itself.
Tried with a config note too - same result: no value parsed into the final html
p.s: ^value($HeadingLevel(“config_note”)[$OutlineDepth])^ will do it
). So, oddly, I didn’t gat quite the same prompt, even on opening the template. Why? Aesthetics. The font designer of the font (here Andale Mono) chose to reassert aesthetics and replace the zero-with-diagonal-bar (a normal zero with cross-strike) with a dot on the middle of the character.
