No need to apologise. We all started at some point. In Tinderbox you are trading power for some learning. Instead of ‘wizard’ buttons that do a task for you with minimal choice as to outcome, you decide what you want to and write the action code. This also means there is usually no ‘correct’ way to do a task, but several although at least one is likely to suit your style of work (but might be the worst choice for some other user).
So, “what is the right way…?” thinking doesn’t help with this tool. Instead, embrace constraints: things you can’t or don’t like to do. Avoid those. Pick a solution that’s closest to how you like to do things. But if your looking for dialogs where you type in the boxes and click the “shown me the answer” button, you may be disappointed. There is some truth in the movie quote “With much power comes much responsibility”. The more choice we ask for from a developer, the more we have to learn to do the choice we have made. this is not least because of the false assumption that we all to the same thing in the same style. The community may be small here but Tinderbox users are doing very different things. Whether it is personal style of work, process or subject area or all of these, it isn’t the same experience.
‘Leaning’ has become a proxy insult for bad design, but I think it is wrong. Tinderbox is not ‘hard’ but it does repay a willingness to learn and just assume your very personalised task is a button somewhere in the app.
The community will help, as shown by the very detailed demo written for you this morning taking >1 hour of somebody else’s free unpaid time to write. In that context, complaining about learning can feel like asking others to to you work for you. I’m not implying you are ding that but simply pointing out the complaint about learning my fall on deaf ears here. We’re willing to share what we’ve learned in the hope others will learn and pass it on. Fine control doesn’t come from type-in-box solutions (unless you’re paying top $ for a personal solution).
Start with a real world question, as you did with the word count one. This makes it easier to define the question and to build a test.
When using queries, you are essentially asking the computer “give me a list of …”. The parts to the query are a series true/false questions. Not necessarily literally. thus we might ask give me the child notes of container ‘XYZ’ that have more than 20 words. This takes query 2 terms. First, the items inside ‘XYZ’
inside("XYZ")
and they must have something else, the & below:
inside("XYZ") &
and that is having a word count of over 20 words:
inside("XYZ") & $WordCount > 20
Tada! Query done. All of that is written in action code. All the parts of the above query you can look up in this listing that’s the learning part. First you figure out the question you want to ask, then state it in terms the program can understand (action code), then use it in your document. It’s not complicated; i’,m able to explain this to you now only because I’ve previously followed those same steps and learned through practice and repetition.
The biggest assist to is to try things out with a problem, e.g. “can I calculate the word count from all the notes in the is branch of the outline?” is better than “how do I total things?”. Then, just as in the example TBX file you provided us you can then test the solution and, having checked you get the desired result use the code/knowledge in you main work files. As the latter tend to be larger and more complex, doing small tests is always go as there are fewer possible conflicting things. Thus, if a technique works in a small test TBX but fails in a bigger one, the failure is not the technique but other pre-existing code in you big document that is interfering. that insight alone can save hours, days of head-scratching (speaking for long experience).
I hope that’s helped explain things a bit more. 