#11588 closed defect (wontfix)
intermediateChanges=true breaks priorityChange
Reported by: | Karl Tiedt | Owned by: | Douglas Hays |
---|---|---|---|
Priority: | high | Milestone: | tbd |
Component: | Dijit | Version: | 1.5 |
Keywords: | dijit.form.TextBox onChange priorityChange | Cc: | |
Blocked By: | Blocking: |
Description
At least in textbox's (first test that came to mind that was quickly proven on) If you goto our test_validate.html under dijit/form/ and do dijit.byId('q01').attr('value', 'blah blah', false); you will see onChange textbox updates everytime... however if you do dijit.byId('q01').intermediateChanges=false; and repeat the test... onChange no longer fires.
possibly relates to other widgets - cant think of any others off the top of my head that also make use of intermediateChanges
Change History (3)
comment:1 Changed 12 years ago by
Owner: | set to Douglas Hays |
---|
comment:2 Changed 12 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Closing this as wontfix until a new design can be agreed upon. I don't completely buy the argument that developers never want onChange to fire when priorityChange=false and intermediateChanges=true. Those developers who want onChange to fire in that scenario are just not complaining since it's currently working properly for them.
comment:3 Changed 9 years ago by
Just FYI, in 2.0 this will all be different because there won't even be a priorityChange flag.
But also, in 2.0, since widgets will be implemented as custom elements, the behavior of all the <input> based widgets will really need to match a plain <input> as much as possible. IIRC that means that onchange doesn't fire when the value is set programatically.
Yes, this is actually "working as designed", but the design needs to change. IOW there needs to be a simple way for an app to set the value programatically without triggering onChange(), but still get onChange() notifications for every keystroke.