Ah, well spotted. I'm glad you have it working and thank you for updating the thread. I still can't replicate the behaviour you saw. It's perfectly valid to use "control" so long as that field doesn't get modified. Oh well, so long as you're up and running. Regards, James

Hi, This is a security feature of Uniface DSPs that is making sure no one is fiddling with the page before sending it back to the server. Your onChange trigger by default will have input/output scope meaning that the DSP the field is on will be submitted back to the server, processed and sent back out to the browser. During the process of reconnecting the DSP on the server Uniface compares read-only field values to hashes also present in the DSP. This is what causes the error here. TAB.MENU.CONTROL has been altered in some way and Uniface is alerting you to this. What widget type is TAB.MENU.CONTROL? Does it's value get modified at any point between the DSP being loaded from the server and the onChange trigger firing? Regards, James

Is a FlatButton_updatable used for creating tabs and i don't think it's value is being modified. I'm just using the OnChange trigger to save the input on a text area in another part of the DSP, is not even in the same Entity.

Hmm strange. I was going to suggest changing the widget type to an _updatable one. That should prevent the hash check from happening as you're telling Uniface that it's OK to update this field in the browser. The error is definitely to do with that though. From the webload documentation: "Mismatch between the security hash of a field and the field value. This occurs when the value of a NED field has been modified by the browser or other web user agent." Is TAB.MENU.CONTROL set to NED? The message is confusing me a bit. I don't think the fact that it's a non-db field should matter at all to webload. Can you switch a debugger on and just confirm that it's webload throwing the error? You'll find that in the getstate trigger.

TAB.MENU.CONTROL only have a C1 Interface.    And yes the message appears just after the webload.

That's really strange. It's editable, it's up-datable, so there's no reason the hash check should be complaining. I'm afraid this might be a situation where we need to try and get a test case together. Do you have anything you could send over to myself or support to take a look at?

So I solved the problem yesterday, the characteristics was set to be "Control" and that was making the error, then i changed it to "Non-Database"