You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@flex.apache.org by er...@apache.org on 2013/05/14 10:41:27 UTC
[1/2] git commit: [flex-sdk] [refs/heads/develop] - FLEX-33505:
NumericStepper not updating on 'change'
Updated Branches:
refs/heads/develop 2afdd2534 -> 4d747868e
FLEX-33505: NumericStepper not updating on 'change'
Both the MX and Spark versions of the NumericStepper didn't have properly set up 'change' event handlers. Without these the value was not committed when no external event (focus out, button click) was trigered.
Signed-off-by: Erik de Bruin <er...@ixsoftware.nl>
Project: http://git-wip-us.apache.org/repos/asf/flex-sdk/repo
Commit: http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/0ec8262e
Tree: http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/0ec8262e
Diff: http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/0ec8262e
Branch: refs/heads/develop
Commit: 0ec8262e8baa6cc6064d65e4227d640bbbf01c02
Parents: e1649ef
Author: Erik de Bruin <er...@ixsoftware.nl>
Authored: Tue May 14 10:40:43 2013 +0200
Committer: Erik de Bruin <er...@ixsoftware.nl>
Committed: Tue May 14 10:40:43 2013 +0200
----------------------------------------------------------------------
.../projects/mx/src/mx/controls/NumericStepper.as | 9 +---
.../spark/src/spark/components/NumericStepper.as | 37 ++++++++++----
2 files changed, 28 insertions(+), 18 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/flex-sdk/blob/0ec8262e/frameworks/projects/mx/src/mx/controls/NumericStepper.as
----------------------------------------------------------------------
diff --git a/frameworks/projects/mx/src/mx/controls/NumericStepper.as b/frameworks/projects/mx/src/mx/controls/NumericStepper.as
index 3c188d3..dd82b1b 100644
--- a/frameworks/projects/mx/src/mx/controls/NumericStepper.as
+++ b/frameworks/projects/mx/src/mx/controls/NumericStepper.as
@@ -1690,13 +1690,8 @@ public class NumericStepper extends UIComponent
// Stop the event from bubbling up.
event.stopImmediatePropagation();
- var inputValue:Number = Number(inputField.text);
- if ((inputValue != value &&
- (Math.abs(inputValue - value) >= 0.000001 || isNaN(inputValue))) ||
- inputField.text == "")
- {
- _value = checkValidValue(inputValue);
- }
+ // fixes FLEX-33505
+ takeValueFromTextField(event);
}
}
http://git-wip-us.apache.org/repos/asf/flex-sdk/blob/0ec8262e/frameworks/projects/spark/src/spark/components/NumericStepper.as
----------------------------------------------------------------------
diff --git a/frameworks/projects/spark/src/spark/components/NumericStepper.as b/frameworks/projects/spark/src/spark/components/NumericStepper.as
index 6a45b32..557d58a 100644
--- a/frameworks/projects/spark/src/spark/components/NumericStepper.as
+++ b/frameworks/projects/spark/src/spark/components/NumericStepper.as
@@ -681,9 +681,13 @@ public class NumericStepper extends Spinner
if (instance == textDisplay)
{
+ // fixes FLEX-33505
+ textDisplay.addEventListener(Event.CHANGE,
+ textDisplay_changeHandler);
+
textDisplay.addEventListener(FlexEvent.ENTER,
textDisplay_enterHandler);
- textDisplay.addEventListener(FocusEvent.FOCUS_OUT,
+ textDisplay.addEventListener(FocusEvent.FOCUS_OUT,
textDisplay_focusOutHandler);
textDisplay.focusEnabled = false;
textDisplay.maxChars = _maxChars;
@@ -893,16 +897,27 @@ public class NumericStepper extends Spinner
}
- /**
- * @private
- * When the enter key is pressed, NumericStepper commits the
- * text currently displayed.
- */
- private function textDisplay_enterHandler(event:Event):void
- {
- commitTextInput(true);
- }
-
+ /**
+ * @private
+ * When text is typed in, NumericStepper commits the
+ * text currently displayed.
+ */
+ // fixes FLEX-33505
+ private function textDisplay_changeHandler(event:Event):void
+ {
+ commitTextInput(true);
+ }
+
+ /**
+ * @private
+ * When the enter key is pressed, NumericStepper commits the
+ * text currently displayed.
+ */
+ private function textDisplay_enterHandler(event:Event):void
+ {
+ commitTextInput(true);
+ }
+
/**
* @private
* When the enter key is pressed, NumericStepper commits the
Re: [1/2] git commit: [flex-sdk] [refs/heads/develop] - FLEX-33505: NumericStepper not updating on 'change'
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
And perhaps even this one?
https://issues.apache.org/jira/browse/FLEX-23746
Justin
Re: [1/2] git commit: [flex-sdk] [refs/heads/develop] - FLEX-33505:
NumericStepper not updating on 'change'
Posted by Alex Harui <ah...@adobe.com>.
OK, I jumped in. I posted two versions of a test case that I mostly got
from the examples in the doc.
[1] http://people.apache.org/~aharui/NumericStepperTest4.9.swf
[2] http://people.apache.org/~aharui/NumericStepperTest.swf
The first one is built on 4.9, the second on what is checked into
flex-sdk. Unfortunately, there is an undesirable behavior change that
becomes apparent if you run the app, select the text in the
NumericStepper, and then try to type "-1.5" and hit Tab. In the 4.9
version it changes the label to -1.5 when you hit tab, in the current code
it shows NaN as soon as you type the '-' and then again when you type the
'.'.
So, I'm going to go back to the test cases in the bugs and see if I can
find another solution.
-Alex
On 5/14/13 11:07 AM, "Alex Harui" <ah...@adobe.com> wrote:
>OK, I will jump in ;-)
>
>
>On 5/14/13 10:51 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>> Crap, I've run out of time.
>>
>> EdB
>>
>>
>>
>> On Tue, May 14, 2013 at 7:49 PM, Alex Harui <ah...@adobe.com> wrote:
>>>
>>>
>>>
>>> On 5/14/13 10:15 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>
>>>> Alex,
>>>>
>>>>> exciting, but I feel like there is still enough activity in the
>>>>>existing
>>>>> Flex SDK to warrant spending time to make sure we don't inject
>>>>>issues that
>>>>> prevent folks from switching to Apache Flex. And I see it as my
>>>>>role to
>>>>> tackle the nasty regressions like that ADG cursor issue that you
>>>>>looked at
>>>>> earlier today that are just going to take too much of volunteer time.
>>>>
>>>> To be sure: that issue turned out to have nothing to do with ADG at
>>>> all. It has it's roots in CursorManager or something deeper. I've
>>>> included example code in the JIRA issue that shows and abstracts the
>>>> same behaviour in a Button subclass.
>>> Yes, thanks for looking at it. I'm still guessing that it has to do
>>>with
>>> some behavioral difference between FXG and SWF assets, but I won't be
>>> getting into it until after I get mustella running clean and checking
>>>out
>>> this potential issue with bound validators.
>>>>
>>>>>> It was my understanding that a bug is considered fixed if it doesn't
>>>>>> break prior tests and fixes the issue at hand. Am I wrong?
>>>>> I think as a volunteer you are welcome to use your definition, but
>>>>> unfortunately, even 30,000 mustella tests are not an exhaustive
>>>>>check of
>>>>> the
>>>>> current code and don't pick up performance and memory leak issues, so
>>>>> that's
>>>>> why I keep quickly scanning commits. To me, if I spend a few
>>>>>seconds to
>>>>> catch something before it goes out, it is the right use of my time.
>>>>
>>>> You make it sound like I came up with that 'definition'. I think the
>>>> workflow I refer to - fix, test (Mustella, checkintests), commit - is
>>>> understood by most committers to be THE way to contribute. If there
>>>> are other requirements, we (you?) need to document those so the few
>>>> contributors that still dare to touch the SDK know how to properly
>>>> work on it...
>>>>
>>> I guess I thought folks knew that mustella wouldn't catch everything,
>>>and
>>> even if you think you nailed it, the review process or the bug author
>>>might
>>> still find something, but I'll try to find time to make that more
>>>explicit.
>>>
>>> But again, as volunteer, you can always say "crap, I've run out of
>>>time" and
>>> hopefully somebody else will jump in.
>>>
>>> --
>>> 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
Re: [1/2] git commit: [flex-sdk] [refs/heads/develop] - FLEX-33505:
NumericStepper not updating on 'change'
Posted by Alex Harui <ah...@adobe.com>.
OK, I will jump in ;-)
On 5/14/13 10:51 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> Crap, I've run out of time.
>
> EdB
>
>
>
> On Tue, May 14, 2013 at 7:49 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>>
>>
>> On 5/14/13 10:15 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>
>>> Alex,
>>>
>>>> exciting, but I feel like there is still enough activity in the existing
>>>> Flex SDK to warrant spending time to make sure we don't inject issues that
>>>> prevent folks from switching to Apache Flex. And I see it as my role to
>>>> tackle the nasty regressions like that ADG cursor issue that you looked at
>>>> earlier today that are just going to take too much of volunteer time.
>>>
>>> To be sure: that issue turned out to have nothing to do with ADG at
>>> all. It has it's roots in CursorManager or something deeper. I've
>>> included example code in the JIRA issue that shows and abstracts the
>>> same behaviour in a Button subclass.
>> Yes, thanks for looking at it. I'm still guessing that it has to do with
>> some behavioral difference between FXG and SWF assets, but I won't be
>> getting into it until after I get mustella running clean and checking out
>> this potential issue with bound validators.
>>>
>>>>> It was my understanding that a bug is considered fixed if it doesn't
>>>>> break prior tests and fixes the issue at hand. Am I wrong?
>>>> I think as a volunteer you are welcome to use your definition, but
>>>> unfortunately, even 30,000 mustella tests are not an exhaustive check of
>>>> the
>>>> current code and don't pick up performance and memory leak issues, so
>>>> that's
>>>> why I keep quickly scanning commits. To me, if I spend a few seconds to
>>>> catch something before it goes out, it is the right use of my time.
>>>
>>> You make it sound like I came up with that 'definition'. I think the
>>> workflow I refer to - fix, test (Mustella, checkintests), commit - is
>>> understood by most committers to be THE way to contribute. If there
>>> are other requirements, we (you?) need to document those so the few
>>> contributors that still dare to touch the SDK know how to properly
>>> work on it...
>>>
>> I guess I thought folks knew that mustella wouldn't catch everything, and
>> even if you think you nailed it, the review process or the bug author might
>> still find something, but I'll try to find time to make that more explicit.
>>
>> But again, as volunteer, you can always say "crap, I've run out of time" and
>> hopefully somebody else will jump in.
>>
>> --
>> 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
Re: [1/2] git commit: [flex-sdk] [refs/heads/develop] - FLEX-33505:
NumericStepper not updating on 'change'
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Crap, I've run out of time.
EdB
On Tue, May 14, 2013 at 7:49 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 5/14/13 10:15 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>> Alex,
>>
>>> exciting, but I feel like there is still enough activity in the existing
>>> Flex SDK to warrant spending time to make sure we don't inject issues that
>>> prevent folks from switching to Apache Flex. And I see it as my role to
>>> tackle the nasty regressions like that ADG cursor issue that you looked at
>>> earlier today that are just going to take too much of volunteer time.
>>
>> To be sure: that issue turned out to have nothing to do with ADG at
>> all. It has it's roots in CursorManager or something deeper. I've
>> included example code in the JIRA issue that shows and abstracts the
>> same behaviour in a Button subclass.
> Yes, thanks for looking at it. I'm still guessing that it has to do with
> some behavioral difference between FXG and SWF assets, but I won't be
> getting into it until after I get mustella running clean and checking out
> this potential issue with bound validators.
>>
>>>> It was my understanding that a bug is considered fixed if it doesn't
>>>> break prior tests and fixes the issue at hand. Am I wrong?
>>> I think as a volunteer you are welcome to use your definition, but
>>> unfortunately, even 30,000 mustella tests are not an exhaustive check of the
>>> current code and don't pick up performance and memory leak issues, so that's
>>> why I keep quickly scanning commits. To me, if I spend a few seconds to
>>> catch something before it goes out, it is the right use of my time.
>>
>> You make it sound like I came up with that 'definition'. I think the
>> workflow I refer to - fix, test (Mustella, checkintests), commit - is
>> understood by most committers to be THE way to contribute. If there
>> are other requirements, we (you?) need to document those so the few
>> contributors that still dare to touch the SDK know how to properly
>> work on it...
>>
> I guess I thought folks knew that mustella wouldn't catch everything, and
> even if you think you nailed it, the review process or the bug author might
> still find something, but I'll try to find time to make that more explicit.
>
> But again, as volunteer, you can always say "crap, I've run out of time" and
> hopefully somebody else will jump in.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [1/2] git commit: [flex-sdk] [refs/heads/develop] - FLEX-33505:
NumericStepper not updating on 'change'
Posted by Alex Harui <ah...@adobe.com>.
On 5/14/13 10:15 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> Alex,
>
>> exciting, but I feel like there is still enough activity in the existing
>> Flex SDK to warrant spending time to make sure we don't inject issues that
>> prevent folks from switching to Apache Flex. And I see it as my role to
>> tackle the nasty regressions like that ADG cursor issue that you looked at
>> earlier today that are just going to take too much of volunteer time.
>
> To be sure: that issue turned out to have nothing to do with ADG at
> all. It has it's roots in CursorManager or something deeper. I've
> included example code in the JIRA issue that shows and abstracts the
> same behaviour in a Button subclass.
Yes, thanks for looking at it. I'm still guessing that it has to do with
some behavioral difference between FXG and SWF assets, but I won't be
getting into it until after I get mustella running clean and checking out
this potential issue with bound validators.
>
>>> It was my understanding that a bug is considered fixed if it doesn't
>>> break prior tests and fixes the issue at hand. Am I wrong?
>> I think as a volunteer you are welcome to use your definition, but
>> unfortunately, even 30,000 mustella tests are not an exhaustive check of the
>> current code and don't pick up performance and memory leak issues, so that's
>> why I keep quickly scanning commits. To me, if I spend a few seconds to
>> catch something before it goes out, it is the right use of my time.
>
> You make it sound like I came up with that 'definition'. I think the
> workflow I refer to - fix, test (Mustella, checkintests), commit - is
> understood by most committers to be THE way to contribute. If there
> are other requirements, we (you?) need to document those so the few
> contributors that still dare to touch the SDK know how to properly
> work on it...
>
I guess I thought folks knew that mustella wouldn't catch everything, and
even if you think you nailed it, the review process or the bug author might
still find something, but I'll try to find time to make that more explicit.
But again, as volunteer, you can always say "crap, I've run out of time" and
hopefully somebody else will jump in.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [1/2] git commit: [flex-sdk] [refs/heads/develop] - FLEX-33505:
NumericStepper not updating on 'change'
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Alex,
> exciting, but I feel like there is still enough activity in the existing
> Flex SDK to warrant spending time to make sure we don't inject issues that
> prevent folks from switching to Apache Flex. And I see it as my role to
> tackle the nasty regressions like that ADG cursor issue that you looked at
> earlier today that are just going to take too much of volunteer time.
To be sure: that issue turned out to have nothing to do with ADG at
all. It has it's roots in CursorManager or something deeper. I've
included example code in the JIRA issue that shows and abstracts the
same behaviour in a Button subclass.
>> It was my understanding that a bug is considered fixed if it doesn't
>> break prior tests and fixes the issue at hand. Am I wrong?
> I think as a volunteer you are welcome to use your definition, but
> unfortunately, even 30,000 mustella tests are not an exhaustive check of the
> current code and don't pick up performance and memory leak issues, so that's
> why I keep quickly scanning commits. To me, if I spend a few seconds to
> catch something before it goes out, it is the right use of my time.
You make it sound like I came up with that 'definition'. I think the
workflow I refer to - fix, test (Mustella, checkintests), commit - is
understood by most committers to be THE way to contribute. If there
are other requirements, we (you?) need to document those so the few
contributors that still dare to touch the SDK know how to properly
work on it...
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [1/2] git commit: [flex-sdk] [refs/heads/develop] - FLEX-33505:
NumericStepper not updating on 'change'
Posted by Alex Harui <ah...@adobe.com>.
On 5/14/13 9:33 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> Alex,
>
> I wasn't being negative at all. I meant literally what I said (keep in
> mind I'm not a native speaker): if you're going to test each commit
> and try to single handedly figure if it will survive every use case,
> you're going to have no time left to actually contribute new code and
> do PMC stuff.
Erik, all I do is scroll through the diff in a few seconds, and if something
catches my eye then I will stop and take a look. Over many years in the
code, certain things like the word "commit" and "addEventListener" and
"stage" make me pay attention.
I have the luxury and privilege to spend all day on Flex. I'm trying to
spend most of my time on new stuff like FlexJS because it is fun and
exciting, but I feel like there is still enough activity in the existing
Flex SDK to warrant spending time to make sure we don't inject issues that
prevent folks from switching to Apache Flex. And I see it as my role to
tackle the nasty regressions like that ADG cursor issue that you looked at
earlier today that are just going to take too much of volunteer time.
>
> It was my understanding that a bug is considered fixed if it doesn't
> break prior tests and fixes the issue at hand. Am I wrong?
I think as a volunteer you are welcome to use your definition, but
unfortunately, even 30,000 mustella tests are not an exhaustive check of the
current code and don't pick up performance and memory leak issues, so that's
why I keep quickly scanning commits. To me, if I spend a few seconds to
catch something before it goes out, it is the right use of my time.
>
> EdB
>
>
>
> On Tue, May 14, 2013 at 6:28 PM, Alex Harui <ah...@adobe.com> wrote:
>> 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" <er...@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 <ah...@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" <er...@ixsoftware.nl> wrote:
>>>>
>>>>> Nice!
>>>>>
>>>>> EdB
>>>>>
>>>>>
>>>>>
>>>>> On Tue, May 14, 2013 at 11:15 AM, Justin Mclean
>>>>> <ju...@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
>>
>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [1/2] git commit: [flex-sdk] [refs/heads/develop] - FLEX-33505:
NumericStepper not updating on 'change'
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Alex,
I wasn't being negative at all. I meant literally what I said (keep in
mind I'm not a native speaker): if you're going to test each commit
and try to single handedly figure if it will survive every use case,
you're going to have no time left to actually contribute new code and
do PMC stuff.
It was my understanding that a bug is considered fixed if it doesn't
break prior tests and fixes the issue at hand. Am I wrong?
EdB
On Tue, May 14, 2013 at 6:28 PM, Alex Harui <ah...@adobe.com> wrote:
> 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" <er...@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 <ah...@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" <er...@ixsoftware.nl> wrote:
>>>
>>>> Nice!
>>>>
>>>> EdB
>>>>
>>>>
>>>>
>>>> On Tue, May 14, 2013 at 11:15 AM, Justin Mclean
>>>> <ju...@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
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [1/2] git commit: [flex-sdk] [refs/heads/develop] - FLEX-33505:
NumericStepper not updating on 'change'
Posted by Alex Harui <ah...@adobe.com>.
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" <er...@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 <ah...@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" <er...@ixsoftware.nl> wrote:
>>
>>> Nice!
>>>
>>> EdB
>>>
>>>
>>>
>>> On Tue, May 14, 2013 at 11:15 AM, Justin Mclean
>>> <ju...@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
Re: [1/2] git commit: [flex-sdk] [refs/heads/develop] - FLEX-33505:
NumericStepper not updating on 'change'
Posted by Erik de Bruin <er...@ixsoftware.nl>.
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 <ah...@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" <er...@ixsoftware.nl> wrote:
>
>> Nice!
>>
>> EdB
>>
>>
>>
>> On Tue, May 14, 2013 at 11:15 AM, Justin Mclean
>> <ju...@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
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [1/2] git commit: [flex-sdk] [refs/heads/develop] - FLEX-33505:
NumericStepper not updating on 'change'
Posted by Alex Harui <ah...@adobe.com>.
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" <er...@ixsoftware.nl> wrote:
> Nice!
>
> EdB
>
>
>
> On Tue, May 14, 2013 at 11:15 AM, Justin Mclean
> <ju...@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
Re: [1/2] git commit: [flex-sdk] [refs/heads/develop] - FLEX-33505:
NumericStepper not updating on 'change'
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Nice!
EdB
On Tue, May 14, 2013 at 11:15 AM, Justin Mclean
<ju...@classsoftware.com> wrote:
> HI,
>
> Actually not that one but I've probably fixed that myself :-)
>
> Justin
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [1/2] git commit: [flex-sdk] [refs/heads/develop] - FLEX-33505: NumericStepper not updating on 'change'
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
Actually not that one but I've probably fixed that myself :-)
Justin
Re: [1/2] git commit: [flex-sdk] [refs/heads/develop] - FLEX-33505:
NumericStepper not updating on 'change'
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Yes, it does... Cool! A twofer ;-)
EdB
On Tue, May 14, 2013 at 10:55 AM, Justin Mclean
<ju...@classsoftware.com> wrote:
> Hi,
>
> Probably also fixes this issue:
> https://issues.apache.org/jira/browse/FLEX-28247
>
> Justin
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [1/2] git commit: [flex-sdk] [refs/heads/develop] - FLEX-33505: NumericStepper not updating on 'change'
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Probably also fixes this issue:
https://issues.apache.org/jira/browse/FLEX-28247
Justin
[2/2] git commit: [flex-sdk] [refs/heads/develop] - Merge branch
'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
Posted by er...@apache.org.
Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
Project: http://git-wip-us.apache.org/repos/asf/flex-sdk/repo
Commit: http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/4d747868
Tree: http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/4d747868
Diff: http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/4d747868
Branch: refs/heads/develop
Commit: 4d747868eebbdce52118260c12e14133a71a632a
Parents: 0ec8262 2afdd25
Author: Erik de Bruin <er...@ixsoftware.nl>
Authored: Tue May 14 10:41:00 2013 +0200
Committer: Erik de Bruin <er...@ixsoftware.nl>
Committed: Tue May 14 10:41:00 2013 +0200
----------------------------------------------------------------------
.../src/mx/controls/AdvancedDataGridBaseEx.as | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
----------------------------------------------------------------------