How to tell if a field is "closed"?

[Geoff Canyon]

I'm sure someone else will come up with something better, but at the least,
don't set a custom property for each field; instead, in the openField set
one custom property for the card or group that the fields are in, something
like "isOpen", with the long id of the open field; then empty that property
on exitField. That way when you import you just have to check that one
property, and if it contains a long id, validate that field.

On Tue, Feb 5, 2019 at 11:25 AM Paul Dupuis via use-livecode <
use-livecode at lists.runrev.com> wrote:

> I have a problem for which I should probably redesign the user
> interface, but would rather not do so for many reasons.
>
> The problem is this:
>
> 1) There are some fields on a card. Each field has a "closeField"
> handler that checks the fields content for validity and presents
> appropriate error messages (via a standard 'answer" command).
> 2) There is an "Import" button that collects the field values and lots
> of other data and does a task in my application.
> 3) If a user edits a fields and enters an invalid value and does not
> click, tab, or press the return key to "close" the field and trigger the
> "closeField" message, but immediately clicks on the "import" button, my
> import script starts using the invalid value from the open field while
> at the same time a closeField message does get send and an answer dialog
> appears telling what is invalid about the entry.
>
> However, my import routine is off and and running with bad data. I need
> a way at the start of the import routine to ensure all fields are closed
> - i.e. that their closeField handlers have ensured the field values are
> correct.
>
> In a worst case, I could solve this by a custom property for each field
> - say valueOK - and set it to false on openField and true on closeFIeld
> or exitFIeld if the edited value valid. The import button would then
> check for any instances where the custom property 'vaueOK' is false, and
> if there are any, exit without running and with an appropriate message.
>
> However, I am wondering if anyone in the LiveCode brain trust has
> figured out a better way to handle something like this?
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>