Unexpected textbox value writtern

Found textbox behavior that creates hard to diagnose issue with values.
On a shared form there is a textbox that stores its data in a bidirectional tag. The normal use case is Operator enters in a value, clicks run. This value is then saved to a new tag while process runs. The textbox is disabled until process is complete. Disabling is based on a tag process.isrunning.

If Operator A types a value into this tag, but does not hit enter, the value is stored someplace in Ignition.

Operator B can then type and enter in a value. This value is displayed on all HMIs. When Operator B starts the process it then disables the textbox.

On Operator A HMI the cursor is now moved out of the texbox when it is disabled. The previously typed in value, which is no longer visible, is now accepted and overwrites the tag. The textbox now shows this previously unaccepted value.

In audits, it looks like Operator A, somehow gained access to the disabled textbox and changed the value.

It may not be common, but this has been causing issues on a customer site. I have not found any way to get around this issue using the textbox settings.

It sounds like the solution is to either not use global tags, or use an exclusive ‘lock’ to the form. Trying to fix this in the text box is the wrong ‘layer’.

I don’t know exactly what your process is, but if you’re writing to a single tag from multiple HMIs you’ve created a human race condition. The easiest way to fix would be a lock; use another tag or some other global object as a sentinel. Once one user opens the window with the form, it’s “theirs”, and any other attempts to open the same window will be rejected. Once they close the window or submit the form, the lock is released. Of course, this then introduces the problem of someone leaving the form open and not submitting it or closing it, but that’s a human problem to solve.

It really sounds like you need to step back from the process and examine what you’re attempting to do more broadly, though.