64 bit CommCtrl v5 SysTreeView32 control broken

[nvaccessAuto]

Reported by jteh on 2009-11-12 02:18
STR:

1. On a 64 bit Windows system, open any chm file.
2. IF not already there, switch to the contents tab by pressing alt+c. You should land in a tree view.
3. Attempt to navigate the tree view with up and down arrows.
   Result: No tree view items are read; you remain focused on the tree view.
   Expected: You should be able to cursor around the tree view and have the active tree view item spoken.

Other info:

• Reported on Windows 7 64 bit. This works fine on Windows 7 32 bit.
• This is a !SysTreeView32. Other !SysTreeView32 controls work just fine; e.g. Device Manager.
• Both !AccessibleChildren and accNavigate with NAVDIR_CHILD on the tree view report E_FAIL, suggesting that MSAA is screwed.
• Apparently, this works fine with JAWS. Maybe there's a difference in-process?
• Forcing NVDA to use UIA here does seem to allow the current item to be read when the tree view gains focus, but arrowing up and down doesn't seem to fire focus events.
  • Interestingly, the same trick works fine in Windows 7 32 bit.

[nvaccessAuto]

Attachment nvda.log added by coffeekingms on 2009-11-27 07:22
Description:
nvda log with possible link to how and why this issue occurs.note two things. i am running nvda from a source tree and not a compiled copy and two, the error messages seem to give a more exact location of the errors then when running from binary.

[nvaccessAuto]

Comment 1 by jteh on 2009-11-12 02:19
This is an important issue, but I don't think we're going to be able to fix it for 2009.1, unless someone has a brainwave.

[nvaccessAuto]

Comment 2 by mdcurran on 2009-12-10 23:47

• Using UIA, UIA definitly does not fire any focus event when moving between items in the treeview.
  It was possible that NVDA was dropping the UIA event due to the hasKeyboardFocus property on the UIAElement being false for some reason, but disabling this check in the code does not improve things.
• Using MSAA, no focus winEvent is fired when moving between items in the treeview. It was thought that perhaps NVDA was dropping the event due to not being able to instanciate the accessible object, but there is definitly no winEvent at all.

[nvaccessAuto]

Comment 3 by jteh on 2010-01-19 03:39
Changes:
Milestone changed from 2010.1 to 2010.2

[nvaccessAuto]

Comment 4 by jteh (in reply to comment 2) on 2010-02-01 07:06
Replying to mdcurran:

• Using MSAA, no focus winEvent is fired when moving between items in the treeview.

On my system (now Win7 64 bit), I do see focus winEvents for this tree view. However, I guess accChild fails, so the object can't be instantiated. How were you testing this?

Interestingly, i still don't see UIA focus events, perhaps because UIA can't get the info it needs to instantiate the object.

[nvaccessAuto]

Comment 5 by mdcurran (in reply to comment 4) on 2010-02-01 07:23
Replying to jteh:

Replying to mdcurran:

• Using MSAA, no focus winEvent is fired when moving between items in the treeview.

On my system (now Win7 64 bit), I do see focus winEvents for this tree view.

Sorry, I was testing with a winSound.Beep in the top of IAccessibleHandler.winEventCallback, if eventID was EVENT_OBJECT_FOCUS. Woerid, but when I do this, I never hear beeps when moving up and down the treeview, yet I hear beeps everywhere else.
But, if I change it to tones.beep, wel... coughs I hear beeps in the treeview.
In short, I varify that we do get winEvents for focus.

[nvaccessAuto]

Comment 6 by jteh on 2010-02-01 07:31
So a fix might be to use UIA to access the tree view objects, but somehow map focus win events for that tree view so they use UIA's objectWithFocus(). That is insane and I don't really think we could manage it without a lot of special case hackery...

I think we really need to notify Microsoft about this one, but unfortunately, I suspect the chances of it being fixed in a patch are almost non-existent.

[nvaccessAuto]

Comment 7 by jteh on 2010-02-16 06:06
This issue occurs on all !SysTreeView32 controls using !CommCtrl version 5. The problem is that:

• HTREEITEM is 64 bit in a 64 bit process.
• IAccessible child IDs are always 32 bit.
• For !CommCtrl v5, there are no separate child IDs, so (64 bit) HTREEITEMs get cast to (32 bit) child IDs.
• This is not safe, as 32 bits of data have been potentially lost, so oleacc doesn't allow it.
  Unfortunately, this means there is no safe solution for this problem except for applications to update to using !CommCtrl v6.
  Changes:
  Changed title from "Contents tree view in Microsoft HTML Help broken on 64 bit Windows" to "SysTreeView32 control from CommCtrl v5 broken on 64 bit Windows"

[nvaccessAuto]

Comment 9 by jteh on 2010-02-17 02:30
For reference, here is the response from Microsoft (pasted with permission):
This bug happens because the V5 CommCtrl TreeView is not accessible on 64-bit operating systems. 
Symptom 1: MSAA cannot see tree view items because the 64-bit OLEACC TreeView provider asks the tree view to map its child ID to an HTREEITEM.  The V5 tree view cannot do this.  On 32-bit machines, you can fall back to casting the child ID to an HTREEITEM, but this is not safe on 64-bit because you lost the upper 32-bits of the data when it was travelling across the 64->32 bit boundary.
Symptom 2: UIA can see the tree view items fine because UIA does not use 32-bit child IDs at all.  However, UIA cannot see tree events.  This is happening because the V5 tree view, when it throws an MSAA event, throws a 64-bit child ID, which gets converted to a 32-bit child ID when you call NotifyWinEvent.  UIA cannot convert the MSAA event to a UIA event because of symptom 1.
...
Next steps:
We are getting in contact with the HTML Help team to ask them to consider binding to V6 Common Controls. we’ll keep you updated on that progress.

[nvaccessAuto]

Comment 10 by jteh on 2010-02-17 06:03
I'm working on a nasty hack to get this working, using UIA to retrieve the information and MSAA for the events. Eeewww.
Changes:
Milestone changed from 2010.2 to 2010.1

[nvaccessAuto]

Comment 11 by jteh on 2010-02-17 06:47
Bzr branch: http://bzr.nvaccess.org/nvda/ticket473/
Changes:
Changed title from "SysTreeView32 control from CommCtrl v5 broken on 64 bit Windows" to "64 bit CommCtrl v5 SysTreeView32 control broken"

[nvaccessAuto]

Comment 12 by jteh on 2010-02-19 00:42
Merged in r3590.
Changes:
State: closed