No problem. Things are rarely obvious before the fact. But, based on the description you’ve given we simply can’t guess further and there’s no judgement.
Acting on my own at advice, at this point I’d make a new small test TBX document showing the problem and upload it. From experience, either making the doc replicate the problem finds the problem or the community here gets a doc where we can figure how the actual behaviour deports form the expectation. Win-win.
With such a doc anyone here can help drill into the problem. Such files only take a few minutes work to make but give massive leverage to help the community here help you.
Thank you so much for your offer to help solve this problem. The file I’m working on contains sensitive information, so I’m trying to figure out how to break off a portion of it in such a way that you can see the issue. I’ll try to sort this out.
Top tip. Top make a tear-down without sensitive data:
Make a copy of the doc.
Ask yourself, are any attribute names really indicating sensitive data? If not, no action but otherwise:
change affected attribute names to a non-indicative name
if changing attribute names, review any relevant code (queries/actions) so that the affected names are corrected
Now cull your actual date notes some you’ve enough to test any queries or action code if() tests. If the tests use sensitive data:
change the queries/actions to use anodyne values
change the remaining notes to use data matching the edits to the above.
Lastly, do not assume the above is “too much” work. Asking others making a problem test rig document just to help you is significantly work than you making a testy rig and even less hard than trying to fix the problem in the full doc. Admittedly, it takes a few such mistakes before this lesson hits home. Also, it is far harder for other people to make up test data that accurately reflects the scenario you (may have inaccurately) described.
@jprint714 and I connected last night, addressed the issues.
Hoverexpressions
The hover expresses was addressed by wrapping a condition around action code that was generating the $Fill and $Hoverimage attribute value. Turns out, if there is a value in these attributes but no associated image the Tinderbox will NOT display the text hover expression. By wrapping a if($Mediafilename!=""){expression} around the code generating the $Fill and $Hoverimage value made it work. If there is no image, then these attributes are not populated and the $Hoverexpression will be displayed.
Hover image not being displayed
They had a value in the TBXConfig note, a user-generated note that stores values, misconfigured. Add the “/” to the path and it started to work.
Mystery note
The team kept trying to delete a note, only to have it reappear. This occurs because of the note creation scripts associated with the link action code I’ve been developing (something we’ve been discussing in the last few meetups). I pointed out that they had different notes with two different names thus Tinderbox was doing what was being asked, to create the notes. As soon as we got the errant spelling go fone fo the attribute value correct the mystery note stopped getting created.
Agents not working
They had notes there were assigned with my Agent prototype, but just assigning a prototype to a note does not make the note an agent. You must create an agent first and then you can assign a prototype to that agent if you’d like. Question for @mwra and @eastgate, what attributes distinguish an agent from a “normal” note? It does not appear that simply adding an agent query does the trick. Are there attributes that you can tweak to turn a normal note into an agent? My guess is no.
For those interested: it is easy to distinguish a note and agent in Map View, but it the outline view it is a bit more subtle. In Map View, the agent will have rounded upper corners and the name on the bottom. In the Outline View, the note will have the dark line along the top and the agent will have it along the bottom.
List Sorting
The team could not figure out why their lists were not properly sorted right. The list is sorted on $Prototype. One of their notes had its badge changed, so it looked like a different note but its prototype was different. Once we assigned the correct prototype, sorting worked.
Moral of the Story
Tinderbox is an incredible power set of tools that help you collect, curate, create, and contribute (publish, share, exchange, express) your insights. These tools will do what you tell them to do. The trick is knowing what you want it to do and then figuring out how to tell Tinderbox to do that. This trick for doing this requires both art and science. Science in that there is a very predictable and reliable syntax to which the scientific method can be applied. Art in the application of this syntax can be implemented in a host of ways to achieve the same end-game. Learning what works for you will take practice. Simply borrowing someone else’s code may help you in the short term, but in the long term, you’ll want to learn the art and the science yourself so that you can do it yourself and make it your own.
Correct. Agents are normally made via the Note menu but action code has a createAgent() action that you might find useful. If using the latter, once the agent exists you then give it a query. Setting a query value is not part of the createAgent() operation.
There is no method to turn a note into an agent or vice-versa, as described here.
Agents have no specific attribute. The normal method to locate agents is to look for items with an $AgentQuery value. Before it is pointed out, it is possible to have an agent with no query or a note with a query value set. However, neither of the latter configurations does anything: the former because the agent doesn’t (yet) know what to match so has no child aliases and the latter because a note cannot function as an agent. It is also possible to have an agent with a valid query but no matches. The latter commonly occurs where an agent has an action that alters an attribute value thus altering the item’s match to the agent query.
Bearing in mind the latter is now possible, I think it would now be useful if an $IsAgent attribute existed which would be true for true for agents (only). That would make it easier to do things like find all agents that have not query set.
Someone with the need might like to formally realise it to Eastgate as a feature request. On the face of it it’s ‘just’ one more system attribute—of which there are already 391! Which begs the question of the need. IOW, I think it would help the developer to have a use case for needing a $IsAgent==true test as opposed to the query $AgentQuery!="".
I can contribute one part of that. In a document like aTbRef there are a lot of agent based listings of codes and attributes based on scope, purpose, data type, etc. Generally in export it is not useful to export the agents’ aliases. But you can’t then use ^childLinks()^ as the target isn’t exported. In short, the upshot is lots of hand setting of various templates and code that over 18 years of use have invariably caused problems. This is because hand setting edge-cases scale badly from tens of notes to thousands of notes—there are too many items to do everything manually. One workaround is to (mis-)use a prototype for all such agents though I could as easily made a user boolean $IsAgent.
But, I think the time has come to formalise the latter as a system attribute. It isn’t egregious as we can tests for separators, adornments, composites, etc., using system attributes provided for just such purpose.
Would it be as effective to introduce an $QueryType that returns one (or more) of a set of “Adornment;Agent;Alias;Note;Prototype;Separator”? Seems the app is collecting most of that data anyway for the Project Inspector. Sorry if this q is too dumb lol
I’m not sure how that helps, as you’d then have to loop through the returned listing. If we have an $IsAgent then we have a simple boolean state test for:
Note vs Agent can be told apart by a putative $IsAgent. An adornment is a special case of note/agent hybrid, but we have…
$IsAdornment indicates an adornment. Test with $AgentQuery is testing for a ‘smart’ adornment.
Notes and agents, can be styled as separators. Test with $Separator. I think agents are allowed this so it can be used as a trick to hide agents on a map.
$IsAlias. Notes and agents can be aliases including when styled as a separator. Adornments cannot have aliases. Test an alias with $IsAlias.
Prototypes. Notes, agents and adornments can all be prototypes. Check via $IsPrototype.
It’s possible to over-think this as some setting combos have no obvious purpose, even if possible.
Thank you for writing all of this up. You’ve described it perfectly, and we greatly appreciate your help throughout this process. As I said, we’ve been trying to solve most of these problems ourselves or via the forum as best we can. But sometimes it’s better to have a quick Zoom discussion to sort out certain issues. @satikusala is a really terrific teacher, and has helped us cement our understanding of how Tinderbox works.
The one issue that we’re struggling with is how to go about solving certain problems and errors. I think our misunderstanding with agents was something that required assistance from someone more experienced; we thought that applying an pAgent prototype to a note would transform it into an agent.
But apart from that, do other users have something like a checklist approach to fixing errors in Tinderbox? Or some way that we can go through a series of checks to ensure we’re doing things properly and reviewing possible errors?
To back up for a minute, many on our team have been apprehensive about jumping into Tinderbox with both feet because it’s a bit daunting, and we sometimes feel lost in it – even after we’ve set things up successfully. Thanks to @satikusala and other users here we’ve built something very special, and better understand and appreciate the utility of what Tinderbox can do.
And so, we’ve become more interested in taking a deeper plunge. But the universal worry is how to handle breakdowns on our own. We often trade in sensitive files, so it’s not really an option for us to upload them to a public forum. And we want to be careful about leaning too much on the generous help of individual users. But we also want to strengthen our understanding of how to identify where the errors lie, and how to fix them on our own. Hence the idea of a checklist – or something else in that regard.
Agent prototype is something I’ve created, it is a user-generated
You could pay them. ;-). Seriously, though. You’re fine. It is one of those gray areas that are tough to manage in communities. It is pretty easy to go over the line and quickly move from giving support, ideas, and sharing code snippets to doing someone else commercial work for them. Personally, I think we’re finding a nice balance.
Yes, I understand that. But beyond the problem we faced with the agent, I’m just trying to figure out if there’s some kind of checkbox troubleshooting process that users employ. This might be a discussion for a separate post. I’m trying to compile notes – in a query / checkbox format – that will help me evaluate my work when I get error codes, and when trying to determine why a function isn’t working as intended.
I’m relieved to hear you feel that way! We don’t want to abuse our privilege, and I’d definitely pay you if I could (of course). Still exploring that and future possibilities, as you know. (I’d hate to tell you about our funding situation…)
