New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NVDA fails to read cells in Excel 2003 #7243

michaelDCurran opened this Issue Jun 2, 2017 · 0 comments


None yet
3 participants

michaelDCurran commented Jun 2, 2017

Steps to reproduce:

Running NVDA 2017.2 and Excel 2003, move around an Excel worksheet with the arrow keys. Note that NVDA does not announce the active cell.
An error is generated in NVDA's log:

ERROR - eventHandler.executeEvent (09:03:43):
error executing event: gainFocus on <NVDAObjects.window.excel.ExcelCell object at 0x04F92BB0> with extra args of {}
Traceback (most recent call last):
  File "eventHandler.pyo", line 143, in executeEvent
  File "eventHandler.pyo", line 91, in __init__
  File "eventHandler.pyo", line 98, in next
  File "C:\Users\User\AppData\Roaming\nvda\addons\remote\globalPlugins\remoteClient\", line 341, in event_gainFocus
  File "eventHandler.pyo", line 98, in next
  File "NVDAObjects\__init__.pyo", line 899, in event_gainFocus
  File "NVDAObjects\window\excel.pyo", line 1413, in reportFocus
  File "textInfos\offsets.pyo", line 392, in getTextWithFields
  File "NVDAObjects\window\excel.pyo", line 948, in _getFormatFieldAndOffsets
  File "comtypesMonkeyPatches.pyo", line 37, in new__getattr__
  File "comtypes\client\dynamic.pyo", line 93, in __getattr__
  File "comtypes\automation.pyo", line 643, in GetIDsOfNames
COMError: (-2147352570, 'Unknown name.', (None, None, None, 0, None))

Technical info:

The 'displayFormat' property does not exist on Excel range objects prior to Excel version 13.0. However, the check (around line 948 of source/NVDAObjects/window/ compares two strings, which does not yield correct results when comparing single digit verses double digit versions. For example:

"8.0" > "12.0"

evaluates to true when really the rest of the code expects false.
Thus we need to convert the part before the decimal point to an integer when comparing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment