Hello, Stefan.
>>> 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).
Ok, then I suggest the following - creating the special branch for me kin
the project and lets say call it accessability. Inside this branch there
will be folders for each ScreenReader that I shall support and I shall place
the scripts for several screen readers under this folder and develop them
increasing the accessability of TSVN for some of the screen readers. Your
opinion on this?
>>> 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.
Stefam, I want to start doing this but the only reason stopping me is that I
am not sure if these builds will be accurate in everyday work - I am using
theb TSVN in several projects and do not want to spoil them. Is it possible
to install several versions on the computer at the same time? One for
testing and for everyday work?
>> 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...
you do not need to intercept all 21 methods of iAccessable interface, only
one - Get_AccValue here because all the others are already providing the
information necessary. Since the iAccessable is the COM inside though a bit
different from others - you have the ability to intercept only the one you
want to in your program.
Thank you.
Serge.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2429963
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-12-12 13:31:24 CET