Comment 2 by mdcurran on 2010-12-02 02:17
Changes:
Milestone changed from 2011.1 to near-term

Comment 3 by aleksey_s on 2011-02-08 08:54
Do you have an idea how to distinguish the status bar from another tool bars with window class of 'MsoCommandBar'?? they seem to have identical role (ROLE_TOOLBAR) and control ID of 0. For me they are different only in name (which is, of course, localized therefore useless). Maybe by location?

Comment 4 by jteh on 2011-06-09 07:10
Changes:
Milestone changed from near-term to 2011.3

Comment 5 by mdcurran on 2011-09-13 00:44
Fixed in 50cc67e.
Changes:
State: closed

Comment 6 by kevinchao89 on 2011-09-13 10:21
Not fixed: NVDA Snapshot Main-4675
In Word and Excel 2010, report application status bar is reporting document/spreadsheet title, where it should:
Word 2010: page x of y, word count, or zoom level.
Excel: ready and zoom level

Comment 7 by kevinchao89 on 2011-09-13 10:22
Changes:
State: reopened

Comment 8 by mdcurran on 2011-09-13 10:47
hmm, you're right, in Office 2010 they use Direct2d to write to the display, which is something we cannot track at all at the moment. Its correct for this ticket to stay opened, but I will note that the commit does fix it for Office < 2010.

Comment 9 by mdcurran on 2011-09-13 10:49
Moving to near-turm as we probably can't manage any larger change needed for 2011.3.
Changes:
Milestone changed from 2011.3 to near-term

Attachment fix - 649 - status bar in office 2010.patch added by manish on 2013-06-27 12:47
Description:
fix for excel, word, and outlook
Update:
File added from Trac.
fix - 649 - status bar in office 2010.zip

Comment 10 by manish on 2013-06-27 12:49
The attached patch fixes the problem in word, excel and outlook 2010.
This patch is required because Api.GetStatusBar() method uses IAccessible.GetAccessibleObjectFromPoint to try to get the status bar.
The status bar object in office applications implement both UIA and IAccessible. the UIA role property correctly returns role_statusbar while the IAccessible role property returns role_propertypage for the same object.
Since api.GetStatusBar() method tries to access the role property from the IAccessible interface, it never finds the status bar object.
A more longer term fix for this problem should fix the GetStatusBar method to use the same API as is returned by the FindBestAPI method instead of relying on IAccessible alone.
Thoughts?

Comment 11 by jteh on 2013-06-28 00:36
Thanks for the patch and the info.

We should probably fix api.getStatusBar to use api.getDesktopObject().objectFromPoint instead of using IAccessible specifically. However, even if we did, it appears (at least in Office 2007) that object doesn't report as being native UIA, so we would never use UIA for it anyway. Also, this doesn't fix the problem on Windows Vista and below where UIA isn't available for NVDA.

One concern I have with the patch is that it relies on the string "Status Bar", which is probably different in non-English versions of Office.

Comment 12 by nishimotz on 2013-06-28 10:31
With Japanese Windows 8 and Japanese Microsoft Excel 2013, above patch contributed by Manish worked with the modification as follows:

-               if obj.role==controlTypes.ROLE_PROPERTYPAGE and obj.name.startswith("Status Bar"):
+               if obj.role==controlTypes.ROLE_PROPERTYPAGE and obj.name.startswith(u"\u30b9\u30c6\u30fc\u30bf\u30b9 \u30d0\u30fc"):

However, I don't know such a approach is appropriate or not.

Comment 13 by manish (in reply to comment 11) on 2013-06-28 10:58
James, In the attached patch, using getDesktopObject().objectFromPoint() did fix the problem. Office status bars are now picked using the UIA reported role.

For vista and earlier systems without UIA, we may still need the earlier patch. I have asked Takuyasan to test this with Japanese office to see if it works.

This fix has an impact on ticket #2816. The status bar window class name is "NetUIHWND" and if we use the desktopObject.objectFromPoint() fix here, we cannot put this class name in BadUIAWindowClassNames collection as we were planning to fix ticket 2816.

Replying to jteh:

Thanks for the patch and the info.

We should probably fix api.getStatusBar to use api.getDesktopObject().objectFromPoint instead of using IAccessible specifically. However, even if we did, it appears (at least in Office 2007) that object doesn't report as being native UIA, so we would never use UIA for it anyway. Also, this doesn't fix the problem on Windows Vista and below where UIA isn't available for NVDA.

One concern I have with the patch is that it relies on the string "Status Bar", which is probably different in non-English versions of Office.

Comment 14 by manish (in reply to comment 12) on 2013-06-28 11:01
Thanks Takuyasan. I don't think we can go with this approach of putting in language specific strings to compare. James, for now, we'll need to go with the second patch only where we fix api.getStatusBar. For vista and older systems without UIA, I'll try to think of something.

Replying to nishimotz:

With Japanese Windows 8 and Japanese Microsoft Excel 2013, above patch contributed by Manish worked with the modification as follows:

-               if obj.role==controlTypes.ROLE_PROPERTYPAGE and obj.name.startswith("Status Bar"):
+               if obj.role==controlTypes.ROLE_PROPERTYPAGE and obj.name.startswith(u"\u30b9\u30c6\u30fc\u30bf\u30b9 \u30d0\u30fc"):

However, I don't know such a approach is appropriate or not.

Attachment fix - 649 - Api.getStatusBar- uses correct api.patch added by manish on 2013-06-28 11:02
Description:
fixes api.getStatusBar
Update:
File added from Trac.
fix - 649 - Api.getStatusBar- uses correct api.zip

Comment 16 by mdcurran on 2013-07-02 04:48
#3323 fixes api.getStatusBar. Now incubating on next. This will allow NVDA to find the status bar in Office 2010 apps. Office 2007 has ist status bar found via display model in most cases. Though if we can easily detct that statusBar propertypage with out needing to look at strings, then this can also be improved.

I can read both the status bar in Word and Excel 2016 using nvda+shift+end in laptop lay-out

Testing on MS Word 2016 and MS Excel 2016: Zoom factor, Word count and macro status etc is reported when pressing NVDA+end or NVDA+shift+end. So at least in word and Excel 2016 I cannot reproduce it. I will test tomorrow in Office 2010.

Tested in MS Office 2010, it works as expected. I cannot reproduce this issue.

@fernando-jose-silva, could you please test this with Office 2013? Thank you.

@Adriani90
I believe I was not the person I wanted to mention, I had not said anything about this call, but I'm glad to be able to help.
I did the test in word 2013 and nvda read the status bar correctly.
Thank you very much.

Thank you @fernando-jose-silva for testing in Word 2013. Closing, as suggested in #649 (comment)