I have numerical fields setup to update a database's value when the component value is changed, in addition, it also updates a "flag" code.
I also have an event, onBlur on that same numeric component that only changes just the flag code if a user clicks on that numeric component and out (as a way of verifying that the user checked the numerical value).
With both the change script and onBlur event, it triggers both scripts, and the onBlur is redundant to what it in the change script.
It seems the change script triggers first and updates the value that I try to check in onBlur, so the onBlur can't compare the original value in the flex repeater params to the new value.
Any clean way to handle this? I guess I could setup another custom property to hold the original value , but thinking there might be a built-in way that I'm missing?
Hi rpavlicek,
I didn't see a built in way of holding previous values in the onBlur event. As you suggested, I think the best way is to create another custom property to hold the previous value.
Is there a reason you can't set this up so that the "flag" logic only exists in the onBlur Event?
So, let's assume you have a background color of... Yellow.
Your goal is to keep that color until a user modifies the field or at least clicks into the field and then clicks out as a way of "confirming"?
That seems like a really bad design to me, where a user could accidentally click into a field and leave without paying attention and accidentally confirming a value. Anytime you have an input, it should be used for one thing and one thing only. In your scenario I would hope for an input field and a button, where clicking the button confirms my value without me needing to change it.
There's no way I can think of to separate out your logic aside from NOT setting the flag during the onChange Script and only doing the flag setting as part of the onBlur Event because you don't seem to care whether a user changed the value, only that they entered and then left the field.
The main reason was that by doing it the way I wanted, was to reduce queries. If a value is changed that has a flag (I should mention not all entry fields have flags), the one query changes the value and flag column, instead of breaking it up (one on change, one with onBlur). Multiple this by more users, it adds up.
To the other point, the flag is more for their purpose, as in the end they need to balance all their end production data that wouldn't be significantly affected by the flag. I believe this design to give the operator the best flow and aesthetics while still giving them helpful guidance in completing their data books.
Also, there are several means of verification throughout the process, including an analyst who verifies things in the end. In the past year (originally in Vision), we have greatly reduced operator time and error this way, however, doesn't mean it's the best, which can be said of any developer or design at any level.