How to intercept ''keystroke'' from value list?

[K1200]

I have a text code field that the user can override by selecting from choices in a drop down value list. But there are a few instances where, based on the content of the record, a change to the displayed code is not permitted.

I want to use a script trigger to intercept the user's selected choice before it changes the field's current value. The script will inform the user of the special case ... and the original code will remain.

I've tried OnObjectEnter, OnObjectKeystroke and OnObjectValidate ... but with each trigger, the code has changed (via the user's selection) before I can find out what it was.

I thought this would be a simple and common case, but if it is, I haven't found it. Among other things, I've read the detailed explanations on the SixFriedRice site, but they don't seem to cover the data cases my script encounters. As a fallback, I am able to restore the code using Undo, but it leaves the problem of determining whether it changed, or not. And the method feels shaky, not robust.

Thanks in advance for any help.

[comment]

See if this helps:

RevertField.zip

[K1200]

Yes, that's a good technique.

In my attempt to get something operational, I came up with this somewhat left-handed way ... also triggered OnObjectModify.

Set Variable ($IsNow ; Value:Table::Field)

Undo/Redo [Toggle]

Set Variable ($Was ; Value:Table::Field)

If [$Was = <Exception>]

  Show Custom Dialog ["Change Not Accepted" ; "<reason> "

Else

  Set Field [Table::Field ; $IsNow ]

End If

Your method is more deterministic ... because, as I mentioned, Undo/Redo seem to be open to "operational eventualities".

Thanks for the response.

BTW, one observation in working with both these methods: OnObjectModify triggers the script even if the object is set to its current value ... so "modify" is does not equal "change", but merely "field accessed by the user".

[comment]

BTW, one observation in working with both these methods: OnObjectModify triggers the script even if the object is set to its current value ... so "modify" is does not equal "change", but merely "field accessed by the user".

I believe "modify" means "edit". Re-entering the same value qualifies because the existing value is overwritten - it doesn't really matter by what. What does matter is that if the record was closed, it is now open and requires either reverting or committing.