Comment 1 by jteh on 2010-06-29 02:43
NVDA definitely doesn't ignore the accName for split buttons. However, I'm getting some odd results here.

I tested with Eclipse I20100601-0800, which is a bit old but not very. :) The first time i tested, I got a whole load of buttons with no names. I inspected the MSAA objects directly using NVDA's Python console and accName() was definitely returning NULL. I ran Narrator and also got no button names.

However, I then restarted Eclipse and the button names were speaking properly. To be sure, I reverted to an earlier snapshot of my vm without Eclipse installed and installed it again. Now I can't reproduce the case where there are no button names, despite using a clean Eclipse install.

I honestly have no idea what's going on here. I can tell you that we don't ignore accName() for split buttons.

Leaving open until we know what's going on here.

Comment 2 by carolyn on 2010-08-25 16:34
I was seeing odd behavior, too. If I hovered over a split button with the mouse, then the MSAA name was always correct, but if I navigated there with the keyboard, MSAA did not even ask the split button for its accName, and so it reported that there was no name. I finally figured out that MSAA was sending get_accName to the split button's child (the drop-down button). Wild.

Anyhow, what I have done is to hook get_accName on the drop-down button child, and now MSAA, and consequently NVDA, happily speak split button names all the time.

So you can close this ticket - I have made the change on my side.
It will be available in Eclipse 3.6.1 and Eclipse 3.7 builds as of tomorrow (20100826).

Comment 3 by jteh on 2010-08-25 20:55
Closing, but I'm curious:

MSAA doesn't really send queries like that itself. NVDA sends MSAA queries like get_accName based on the object that has the focus; i.e. fired the last focus event. If you're seeing queries to the split button's child, this suggests that you're firing a focus event for the split button's child instead of the split button itself. Although your accName fix works, I'd argue that this is the deeper problem.
Changes:
Added labels: worksforme
State: closed

Comment 4 by carolyn on 2010-08-25 21:33
Ah, that makes sense. In fact, I am not explicitly firing focus events anywhere in the tool bar - it's all native win32 tool buttons. So since we are using win32 split buttons, they are doing whatever win32 makes them do when the user tabs to them (i.e. they must be firing a focus event for the split button's child).
I guess when I said "MSAA", I was actually referring to inspect32.

Anyhow, I have a feeling that if I explicitly fired a focus event for the split button rather than the drop-down button child, something else somewhere would be messed up, because the OS still thinks that the thing that really has focus is the drop-down button child. So it is probably best to leave in the accName hack that I have, rather than open a whole new can of worms .

Thanks for the explanation, Jamie! I often forget to think of things from the client-side perspective. ;)