On 11.12.2009 00:09, Serge Tumanyan wrote:
>> That's not good. The hotkey is actually on the group box since the combo
>> box itself doesn't have a text. But according to the MSDN docs, screen
>> readers should do the same as Windows does and use the accelerator of
>> the label/groupbox that comes right before such controls as a combobox
>> in the tab order.
>> For example, a label in front of an edit control with an accelerator key
>> would set the cursor in the edit box. The same applies to the groupbox
>> 'in front' of the combobox (again, in front applies here to the tab
>> order).
>
> Stefan, at last I have understood the problem.
> 1. You have wrapped a combo box into a wrapper with the window class
> 'ComboBoxEx32'. and this stops the screen reader from getting the
> information. If you place the static text field inside the wrapping window
> or totally will remove the wrapping window the situation should become much
> better.
> The windows sequence must be the following:
> Static label (the one you already have)
> Combo box itself (The window with the class 'ComboBox').
> +-- Edit box inside the combobox (the window with the Edit class inside the
> combobox)
> This sequence can be wrapped whatever you want.
>
> And now we have:
> Static label
> The combo box wrapper (the window with the class 'ComboBoxEx32')
> +-- Combo box itself (The window with the class 'ComboBox').
> +-- Edit box inside the combobox (the window with the Edit class
> inside the combobox)
>
> And this messes up the screen readers. Is it possible to move the static
> label inside the wrapper class or remove the wrapper totally?
> Hope that I have drawn the branches correctly visually...
This would be the job of your screen reader. See, the combo box
'wrapper' as you call it with class 'ComboBoxEx32' is actually a windows
control. It's an enhanced version of the very old combo box control, but
even ComboBoxEx32 has been around for years now. Your screen reader
really should know about that new control and recognize it properly.
Since ComboBoxEx32 is not a custom wrapper but a windows control, I
can't move the label inside this wrapper, and I can't get rid of it
either because we need the extended functionality of that control (e.g.,
ComboBoxEx32 has autocompletion and better looks than the plain combo box).
>
>> Of course, I'm using the latest nightly builds (or my own dev builds)
>> and not the 1.6.6 release. Since there are many differences already
>> between those two versions it might be that this is the reason you don't
>> see the accelerator in your screen reader?
>
> May be, if you have already changed the window structure?
The dialogs changed often on trunk, so I'm sure that many dialogs and
their structure has already changed - maybe even to the worse so you
really should start using such a nightly build to make sure we don't
mess up anything for your screen reader.
>>>>> 5. The revision edit box with the ControlID = 1034,
>>>> doesn't have a text either.
>>> See the above discussion on accelerators.
>> It would be possible here to set an invisible label control in front of
>> the edit box which has the accelerator key assigned to it.
>
> Well, yes, you are right. It is not totally important here since you can
> focus on a radio button with the accelerator and tab once to get into Edit
> box, so if you will fix - it will be good, but if not, well, we can live
> with it.
Ok, I'll leave it then.
> Here I can help you, since I am very familiar with MSAA. MSAA gives you its
> own structure of objects that may/may not be dependant on window structure.
> 1. For buttons, checkboxes, edit boxes, combo boxes the MSAA provides only
> one end object - the one that represents the control itself.
> 2. For listboxes, listviews, tree views and some other controls the MSAA
> provides the object representing the control itself and provides some kind
> of children of that object providing info for each item in the control. You
> can access these children by simply providing the number of the child you
> want. For example: oList.Get_accName (1) will access the first item name and
> oList.Get_accName (10) will access the tenth element without paying
> attention if it is visible. This how it works from the client side - the
> screen reader. From the server part you have to provide the property
> accName, accDescription, accValue reacting on the integer that is passed to
> the method Get_accValue and providing the information to the client.
> Returning back to our case you need from the server side provide the
> accValue property with paying attention what is the number passed to it and
> setting up the property accordingly to the information in the listview item
> corresponding to that integer.
That would require to subclass the list control and intercept those
messages and implement the full IAcessible interface and all of its 21
methods.
I really hope there's an easier way to do this. Still going through the
MSDN docs...
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2429932
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-12-12 09:58:15 CET