This file demonstrates a concept I am calling "single field edit". Under every data field is a different copy of the same global field. Script triggers control access to the field, and you can control access, editing, auditing, tab order, etc with a very small set of scripts because all activity is routed through the same field.

In find mode, the user enters the standard data fields.

SingleFieldEdit.fp7.zip

Hi Bruce! This is interesting!

Under every data field is a different copy of the same global field.

I am still exploring your concept but I have one question:

Numbers: If I change State to a number and apply validation (always validate, numeric only, do not allow override) and I enter text then carriage return then text into the State (your global text field), it enters that final (incorrect) value into the audit log [color:green]but reverts the value back to the original.

Dates: If I change Zip to date field, it accepts June 11 as a date (and it shows as June 11 in the audit final value but displays (of course) ? in the date field, [color:green]unless I also change validation to always validate, do not allow user override, then it reverts to prior.

By using global text, you remove 1) the ability for filemaker validation (validations such as numbers not having carriage returns and dates must be true dates, where FM displays automatic message) and 2)specified field-level validations (even custom message with warning won't display). Do you suggest then that a global be provided for these data types instead of global text to protect from issue 1 and then the Developer will need to also protect from issue 2?

Thank you for providing this concept! :smile2:

Edited May 9, 201015 yr by Guest
changed green

I'm sure that a number of details will need to be addressed to make this a more robust solution. Certainly one possibility is that there be a single global field for each data type. And of course - keystroke filtering and validation are scriptable.