Bugzilla – Bug 471330
DateTimePicker: can not change day and year's value from Accerciser's "Text(editable)"
Last modified: 2009-05-07 15:31:53 UTC
PROBLEM STATEMENT: when you input numbers to the spin button of "year" from "Interface Viewer" -> "Text(editable)" of Accerciser, the year on the UI will not be changed. REPRODUCE: 1. launch uia2atk/test/samples/datetimepicker_dropdown.py and accerciser 2. click "ipy" -> "DateTimePicker Control" -> (empty) panel -> 2009 on the left side 3. open "Interface Viewer" on the right side -> "Text(editable)" 4. input numbers between 1753 - 9999 RESULTS: The year's value could NOT be changed from the GUI EXPECTED RESULTS: The year's value could be changed from the GUI COMMENT: I'm not sure it is a bug or a feature, so i file for it. if it's not a bug, I'm sorry for that and please close it. :)
We're not supporting Atk.Text with this, only Atk.Value.
ok... thanks, but i think it would be great if someone update its wiki specification[0]. :) [0] http://www.mono-project.com/Accessibility:_Bridge_Functional_Specification
Hi Brad, it still confuse me, day and year in here are similar to NumericUpDown right? if the answer is 'Yes' please continue :) Please run numericupdown.py that there are two spinbutton, first one is editable from UI that has been supported EditableText and input can change value from UI , second is not editable from UI that has been supported EditableText but input can't change value from UI . So I think day and year spin button in here should similar to first editable spinbutton in NumericUpDown sample, shouldn't similar to second uneditable spinbutton. otherwise we shouldn't implement Text(Editable) or Text. what do you think? thank a lot! (In reply to comment #1) > We're not supporting Atk.Text with this, only Atk.Value.
(In reply to comment #3) > Hi Brad, it still confuse me, day and year in here are similar to NumericUpDown > right? if the answer is 'Yes' please continue :) Similar, but not the same. They're different implementations of the same interfaces. In this particular case, we don't want to implement Atk.EditableText, as the provider supports only RangeValue. I'll fix that in this bug.
Some thoughts: Having the children of DateTimePicker in UIAutomationWinforms implement IValueProvider appears to not be advisable when it comes to the UIA spec and the implementation of UIA in Vista/Win7. Most importantly, it would be a pain in the butt to do this, given the hacky way we had to fabricate the Spinners for the DateTimePicker in the first place. The way that it is done in NumericUpDown is that the provider implements an internal interface (IEditableRangeProvider) by exploiting a feature of that specific control (that we have internal access to the underlying textbox). Since we fake the spinners in the DateTimePicker, we can't use this approach. The only RightWayTM to fix this is by implementing a Spinner class in the Bridge which doesn't implement EditableRange. Unfortunately, without actually copy and pasting code (there is no way we can share this), I can't create a Spinner that implements Atk.Action, Atk.Value and Atk.Text but not Atk.EditableText. This is partly a limitation of Atk+/# and partly a limitation of our overall design. And most importantly, if I were to do this, it would be a large, breaking change that I wouldn't feel comfortable getting into 1.1. For now, I'm going to close this as WONTFIX. We might be able to revisit this later if we end up pulling the new bridge architecture that we're using for Moonlight back into the UiaAtkBridge codebase, but otherwise it's a large time sink for something relatively minor.