Aggressive auto-fill when assigning text to attributes that are sets or lists

Hi, all,

Something goes wrong often in v 9 when I try to add text to the values of some user-defined attributes.

I have several attributes that are sets. Often when assigning a value to one of these attributes, I can pick from one of the members of the set, from a list of words or phrases that drops down as soon as I type a letter or two.

However, it is now nearly impossible to add new text values to the set.

Suppose I have an attribute called Region and the set consists of North, West and South. Instead of picking one of those, I type in a new label – Southeast. Before I can finish it, Tinderbox replaces what I’ve typed with “South.” It won’t let me continue without interrupting me to substitute the text it wants to fill in for me. At other times it wipes out what I’ve started to type and replaces it with a blank.

I’ve created a video capture of the problem occurring, but unfortunately this forum won’t allow uploads of .mov files. I can send it to anyone interested though.

Has anyone else experienced this? I searched the forum but didn’t find anyone else running up against this. This behavior never happened before 9 so I assume I must be stubbing my toe one some new feature or process.

Thoughts and suggestions welcome!

David

I’m sorry about that. However, you can either upload it to your own web space or use a URL links to Dropbox/iCloud/etc.

As to the problem, I’m afraid I’ve not encountered quite the experience you describe.

Good point, Mark. Sorry I didn’t think of this in the first place.

Here is the video. The sudden disappearance of text isn’t me deleting it. It’s Tinderbox replacing what I’ve typed with a blank.

David

Odd is it all values of this set, or a particular string? Either way, could you give a specimen string to try and replicate the issue?

Also, a long shot, but
do you have any code operating on this (note’s) attribute?

Hi, Mark,
Not that I know of. Nor can I replicate this issue in any other document, new or already existing. There must be something about this set that v9 doesn’t like (didn’t have this happening until upgrade) but I don’t know what it could be.

David

If it only happens in one document, which is what I read from your comment, then I’d wager a rule or other action code is (rightly or wrongly) getting involved.

In a toolbox app like Tinderbox this may happen. By all means upoload va TBX (ideally small!) showing the problem or email support. This might be an issue which needs to looks are the code. IOW, inadvertently, it might be user error or it might be a real bug. Too little info to tell at this point.

I have the same issue since working with TB9 and could finally reproduce it.

Pls find attached the example file.

Try to change/extend in node “EXAMPLE HERE” attribute “Motto” and wait at least 15 seconds before confirming it. TB will overwrite the value automatically.

In my case I assume it has something to do with the “Agent 1…3”. I just copied “Agent 1” to reuse it.

example.tbx (192.2 KB)

Thanks, Gernot! I wonder if it is the interaction of more than one agent that causes it? Or perhaps more than one agent with the same action? These are wild guesses. But at least now, thanks to you, we know where to look.

David

Alas, no one else seems to find this of interest, as there have been no more messages about it. I’m grateful to you for showing that it’s a real bug and not a weird idiosyncratic glitch on my system. I hope it gets addressed, some day.

David

It’s likely the result of an agent action that is forcing a screen update.

(Later: it’s an edict that’s refreshing the table. Stay tuned.)

I do see $Motto—the attribute we are being asked to test—is also used in column view. I tried removing $Motto as a view column and the Displayed Attributes input reversion still occurs. Same if I turn checkboxes off.

The example here is not in scope of the agent query, nor does it even use attributes addressed in the query.

Oddly, none of the agents has an action.

I did notice that ‘Agent-2’ and ‘Agent-3’ are exact dupes. So, I changed the query of ‘Agent-3’ to a different one - still finding items but via different criteria. But, the loss of input stopped. So, it may be co-incidence but might the agent duped in all but name be a factor?