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@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@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode