Tinderbox file not waiting for input

I’m having a weird problem with one document. For the past couple of days, when I try to enter anything into an attribute ($Set or $List or $Text) Tinderbox closes the entry line after a few seconds. IOW if I am typing “Baltimore” into a set called $City, I can get in “Balt” before Tinderbox decides I am done and closes the input line. “imore” will then appear in Outline view as if I am typing a search. Something is causing the app to “decide” I am done.

Other docs aren’t having the problem. Neither did this one until a few days ago. So something odd has happened to this file but I can’t figure out what.

So, two questions.

  1. Is there a way to see a history of agents, actions, rules, edicts created, in chronological order? If I have somehow added a problem Rule or Action, that would be an easy way to suss it out.

  2. What the heck can I do about this? I would like to avoid reverting to the pre-problem version of the file, as I would lose some notes.

Thanks!

David

This is a problem for some (fairly exotic) Tinderbox 7.5 documents when an agent or rule has to update the view. For example, an action that changes $Color or $Badge might be responsible.

Manual agent updates are often a viable workaround; we’ll have a fix shortly.

OK, cool. Thanks, Mark. In the meantime manual update does seem to solve the issue.

David

If you’ve not used it do take a look at the Tinderbox Inspector’s Agents & Rules tab. It doesn’t do a history of the type you seek, but it can help give some indication as to the progress of the rule/agent/edit cycles. I certainly tend to check it if I think things are getting gummed up - that’s not a reflection on the app’s performance but rather my use of it!

More info, in case it is useful.

I don’t have any actions that change $Color or $Badge but I do have a Rule that sets $FullName to equal $Name in any note that takes the Person prototype. I set it up to avoid the drudgery of typing the same thing twice (as I call each Person note by the name of the person it is about). I did notice that this seems to cause a lot of processing. Maybe it is the “exotic” move that caused the problem? Anyway, glad there is a fix in the works.

Thanks for the tip. I did in fact do this and discovered a kind of a funhouse mirror of my intentions (what seemed a simple Rule to me ends up being called 368 Rules by Tinderbox). I’m guessing this is the source of the weird behavior, as I just mentioned to Mark B.

Perhaps not obvious before the fact that if a prototype has a rule all notes using that prototype inherit the rule. Thus, if one prototype has 100 inheriting notes there are 101 rules active as the same code is run in the context of each note using it. Furthermore, if such notes are aliases manually or alias an agent, they too add to overall rule count (or edict content, etc.). Thus, sometimes, when spelunking unexpected performance/behaviour, you may need to reverse out those factors from the listed rule total. Still, in the round, I find the dialog very useful.

I see. This is good to know as a general observation about prototypes and aliases and their effects.

However, I see now that such a multiplication of rules didn’t cause this particular problem – at least not by itself. The document was behaving normally until I upgraded to 7.5, even with the prototype bequeathing the rule to all its avatars. Since there is a fix in the works I’ll keep hoping that I can keep this particular rule in the prototype (though I suspect there may be a better way to accomplish what I need to do).

Suggestion: if your rule is

$FullName = $Name

this will constantly set $FullName in every note that inherits the rule. But

$FullName |= $Name

will only set $FullName if it hasn’t already been set. That saves a lot of work.

Alternatively, you might consider using an edict instead of a rule; edicts run less frequently.

Huh. I must be doing something wrong. When I try

$FullName |= $Name

It doesn’t have any effect. A new inheritor of the prototype doesn’t obey that rule.

Not sure what I am missing here.

Just to be clear, is the problem that a note based on the prototype doesn’t have that rule (when you look at in the inspector), so that prototype-inheritance doesn’t seem to be working? Or that in those new notes, the rule is there but is not working the way you’d expect? (Not setting $FullName in new notes.)

Just for clarity about the debugging path. (I find that this kind of rule works OK for me, fwiw)

Good question to ask, thanks for pointing it out.

A quick check shows that the note based on the prototype does have the rule (ie it is inheriting way it should). But the rule doesn’t “work.” Perhaps there is a syntax issue? I typed it as $FullName (space) |= (space) $Name. But I think I have tried the other possible variations (no spaces, space only after |=, space only before |=) and it hasn’t made a difference.

It all works as intended when I do the rule as a simple " = " rather than “|=” .

Is this possibly an inheritance issue? The |= works to set a value once only, but perhaps not in the way you think. If the note you’re using to test with has already had $FullPath set, even if only to no value, it still counts as having a locally set value. In other words, this operator doesn’t set the value to the desired value if the existing value is not the same as some assume. See more on the |= operator.

The easiest way to check if a value is inheriting, i.e. not set locally is to view it by any of:

  • shown as a Key Attribute. If the attribute name and value are listed in bold, a value is set locally (i.e. not inherited).
  • Get Info, attributes tab. As above.
  • Properties Inspector, Quickstamp tab. See linked article for inheritance controls.

Tor the first two methods, use this menu to reset the attributes inheritance. The Quickstamp Inspector has controls to re-set inheritance (see linked article).

Yep, that’s the solution. Thank you!

Value is indeed set locally. Until I figure out why I will go back to the setting that I can understand, even if it takes more processing power. After all, the workload wasn’t causing the trouble – before 7.5 I had no problems with this doc.

David

From experience, it’s often easily done whilst checking why something doesn’t work. We make a change to a note [sic] to fix the problem in front of us but in our mind’s eye, we either/both overlook inheritance or assume we are changing the prototype and not the inheriting note. I’ve done this all too often in the past. :open_mouth:

Been there, done that. But in this case I always made changes to the prototype, so I have to figure out what it is about the notes or their container that blocks my intended result when I use |= .

Do you have a TBX that’s a minimum working example that we might see? Even if it is data you can’t share, making a MWE is often a good way of getting at the problem. If a basic model works, then add back features until it breaks.

Remember that instances of the prototype will inherit $FullName from the prototype. If the rule runs on the prototype, it will populate $FullName, and the prototype’s $FullName, having been inherited, will block |=

So perhaps a better way to do this would be to make the rule an OnAdd for the container that holds all the Person notes? Or make it an OnAdd action?

Except that neither of those moves work. So I am back to putting $Fullname=$Name in the prototype. What it lacks in efficiency and elegance it makes up for by actually doing what I want it to do.

Sure. Here is a super-simple TBX in which $Fullname=$Name as a Rule in the Prototype does the trick. But in which $Fullname |=$Name does not. Also unsuccessful: Making $Fullname=$Name into an OnAdd Action or Rule in the “Person Notes Go Here” container.
EXAMPLEFILE.tbx (56.3 KB)