I think that you are on the right track. I would have a tPending variable with a true value that changes to false when the field is complete. "OnLeave" or "exitField". This variable would not allow any other task as long as the tPending variable is true.
Sincerely, Clarence Martin Email: chi...@themartinz.com Cell: 626 696-5561 -----Original Message----- From: use-livecode <use-livecode-boun...@lists.runrev.com> On Behalf Of Paul Dupuis via use-livecode Sent: Tuesday, February 05, 2019 11:25 AM To: use-livecode@lists.runrev.com Cc: Paul Dupuis <p...@researchware.com> Subject: How to tell if a field is "closed"? 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
