[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Results of testing of latest fixes.

From: Serge Tumanyan <tumanyan_at_mail.ru>
Date: Wed, 23 Dec 2009 01:59:22 +0300

Stefan,

>>> But I've changed the accRole property to "link" for those controls and I
>>> thought that this would be enough for the screen readers to recognize
>>> them as such?
>> I hoped so to. But they are announced as text by mighty screenreaders as
>> JAWS for example, though Thunder that is not very powerfull and takes
>> only
>> MSAA information into account works properly.
> Well, they *are* text labels but clickable - a lot of custom controls
> are based on the label control so I'm not sure why JAWS can't figure
> this out properly.

Usually the window class used for links is completely different from
'Static' and this is the reason why JAWS doesn't catch this properly. I have
checked out and seems that non-MSAA only screenreaders mostly have the same
problem.

>> I am not very familiar with MFC that is used to develop TSVN, but at
>> least
>> using WUI you can for example get the information of a class by calling
>> 'GetClassInfoEx', then change the class name by changing the
>> 'lpszClassName'
>> member of the 'WNDCLASSEX' structure leaving the other fields untouched
>> to
>> preserve the functionality of the newly registered class and
>> 'lpfnWndProc'
>> callback procedure to be taken from original class and then register
>> class
>> by calling 'RegisterClassEx' function - this will not change the
>> functionality of the newly registered class from the original one. Isn't
>> something similar possible in MFC?
> Well, that's certainly possible. But that's not really renaming the
> class but creating a completely new window class and borrowing most of
> the original data from the original window class.

Sure, I clearly understand this - this makes a local copy of the system
class with the different name that is valid for the current process only.

> This only works if the original windowproc function never uses the class
> name for e.g. checks about what to do. And since that's not really
> documented, I don't want to do that - it could change without notice and
> break our link controls completely.

Ok, aren't there any predefined in MFC class of a window to use instead of
links? Links are widely used in original windows interface and their class
is surely not 'Static' and as far as I can understand the amount of MFC
predefined classes is larger then the WUI ones. In case if there is no
predefined class to be used especially for such a case we can leave this as
it is, I shall add some tutor message here and hope that blind users will
work properly with it. At least we made a tremendious progress here and the
accessability is dramatically better now and with some attempt the blind
user can use it rather easily. I just point you the place for further
enhancements to let you know.

Thank you.

Serge.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2432448

To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-12-23 00:00:01 CET

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.