Hi Erik, I really appreciate the time and effort you are taking to fix bugs, but I do try to review as every commit to make sure we don't introduce new issues. I sure hope someone is reviewing my commits. I am not trying to find a different or better way. To me, this is similar to happening to see a missing null check or a code path that can cause a memory leak. And, I'm trying to educate all committers on the past practices and philosophies of the SDK development, although just because we used to do something a certain way doesn't mean we still should.
I understand your time is limited and you are all volunteers. If you don't have any more time to spend on this issue, I will take the time to test to see if there is a new and undesirable behavior with bound validators and report back. And thanks for at least taking the time to run mustella! -Alex On 5/14/13 9:16 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: > Alex, > > If you're going to check every commit and figure out a different way > to do it, you're going to burn yourself out long before you get to > finish FlexJS, man! > > I added the a change event handler to the Spark control and changed > the change handler on the MX control. Mustella tests (240 something) > for NumericStepper and the check-in tests all pass. I thought that > meant that I didn't break existing functionality. Since the test case > with this bug and some I wrote myself now function as intended, I > figure I have done my due diligence and that my fix fixes the bug. I'm > sure there are other (better!?) ways to do this, but this is what I've > got. > > EdB > > > > On Tue, May 14, 2013 at 5:37 PM, Alex Harui <aha...@adobe.com> wrote: >> Erik, >> >> Thanks for looking into these issues. I'm wondering if this is the right >> fix, though. I haven't actually pulled your changes, so I'm just looking at >> the diff. >> >> It appears that this commit switches from a change event on enter to a >> change event on every keystroke in the TextInput portion of the >> NumericStepper. If I didn't read it right, then ignore the rest of this >> email. My concerns are that this will trigger databinding on every >> keystroke, and will trigger validators on every keystroke as well, which >> could cause invalid results temporarily since many numbers may be out of >> range as you type. For example, if you wanted to enter "-1" the validator >> may trigger as soon as you type '-'. >> >> In reading the two bugs, it makes me think that something else is broken >> regarding FLEX-33505. As soon as the user clicked on something to dismiss >> the popup, focus should have been lost which should have triggered a >> FOCUS_OUT which should have caused the NS to commit its text. The other bug >> also implies that NS is not handling FOCUS_OUT correctly, so maybe there is >> a fix needed in FOCUS_OUT handling. >> >> I believe there are several places in the Flex SDK where a CHANGE event is >> not dispatched from the component until you lose focus or hit ENTER so that >> binding and validators don't fire so often. >> >> If my understanding is correct, can you revisit this fix? >> >> >> On 5/14/13 2:22 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: >> >>> Nice! >>> >>> EdB >>> >>> >>> >>> On Tue, May 14, 2013 at 11:15 AM, Justin Mclean >>> <jus...@classsoftware.com> wrote: >>>> HI, >>>> >>>> Actually not that one but I've probably fixed that myself :-) >>>> >>>> Justin >>> >>> >> >> -- >> Alex Harui >> Flex SDK Team >> Adobe Systems, Inc. >> http://blogs.adobe.com/aharui >> > > -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
