Community
Participate
Working Groups
R3.0 v2003627 The titles of tabs are not being read by JAWS 4.51 in build v20030627. However WindowEyes works fine so I suspect an issue with JAWS itself.
This is because we had to subclass the Windows control in order to work around a Windows problem where the tab control redraws on resize, causing fairly bad flashing of any child controls (in our subclass, we turn off the HREDRAW and VREDRAW control style bits). Subclassing requires that you provide a new Window Class Name. So JAWS is looking for a window class named "SysTabControl32", but the name of our control is "SWT_SysTabControl32". The only difference is that those 2 bits are turned off. I will investigate to see if I can find a way to fool Windows into thinking our control's name is actually "SysTabControl" or "SysTabControl32", however, in the meantime, there is a JAWS work-around that does work. With Eclipse and JAWS both running, give focus to one of the tabs of a Tab control (you may have to use ctrl+tab and/or shift+tab to get there). Then type "INSERT + 7". In the "New Class" field of the dialog that opens, make sure it says "SWT_SysTabControl32". Select "TabControl" in the "Assign to:" list, and the click the "Add Class" button. Then press "OK". This tells JAWS to treat anything named "SWT_SysTabControl32" as if it was a system tab control (which it is...).
OK, I have a fix. On Windows, you can register a local window class (ours) with the same name as a global class (SysTabControl32). According to the doc, this will not affect other applications or even processes that create a control with that class name - they just get the original global class. I was worried at first that other native code that was running *in-process* (i.e. native dialogs like the print dialog have a SysTabControl32, or maybe Active X controls that happen to use SysTabControl32) might get our subclassed window class. This would be bad because since we turn off the HREDRAW and VREDRAW control style bits, they would get cheese on resize (we don't because we work around it in the window messages). But I tested this possibility really well and didn't find a problem, and I read the fine print of the Windows doc, and it looks like any other non-SWT in-process code is getting the original class... probably because they use a different module instance than we do when they create the control. (i.e. They use the common controls dll, and we use the swt dll). Anyhow, the bottom line is that Window-Eyes and JAWS now read TabFolder tabs. Fixed as of > 20031211.
*** Bug 15779 has been marked as a duplicate of this bug. ***
