Loading Windows OCR settings panel results in cluttered UI

[cary-rowen]

Steps to reproduce:

1. Press NVDA + N, P, S in turn
2. Navigate in the Settings category.
3. Navigate to the WindowsOCR category, press tab to observe the UI

Actual behavior:

Shows some controls for document navigation
log snippet

ERROR - unhandled exception (11:01:35.008) - MainThread (5244):
Traceback (most recent call last):
  File "gui\settingsDialogs.pyc", line 4149, in onCategoryChange
  File "gui\settingsDialogs.pyc", line 667, in onCategoryChange
  File "gui\settingsDialogs.pyc", line 649, in _doCategoryChange
  File "gui\settingsDialogs.pyc", line 577, in _getCategoryPanel
  File "gui\settingsDialogs.pyc", line 335, in __init__
  File "gui\settingsDialogs.pyc", line 345, in _buildGui
  File "gui\settingsDialogs.pyc", line 2598, in makeSettings
  File "gui\guiHelper.pyc", line 332, in addLabeledControl
  File "gui\guiHelper.pyc", line 205, in __init__
TypeError: Item at index 0 has type 'NoneType' but a sequence of bytes or strings is expected

Expected behavior:

Show the settings ui for Windows OCR

NVDA logs, crash dumps and other attachments:

log.txt

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2023.1

Windows version:

Windows 10 1809 (10.0.17763)

Name and version of other software in use when reproducing the issue:

None

Other information about your system:

None

Other questions

Does the issue still occur after restarting your computer?

Yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

No

If NVDA add-ons are disabled, is your problem still occurring?

Yes

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

Yes

[CyrilleB79]

@cary-rowen do you confirm that you have tested with add-ons disabled? Just because your log shows that NVDA is running with add-ons.

Also is there any reason why you are running Windows 10 1809, which is an old release now unsupported by Microsoft?

I suspect an unknown language to be installed in Windows OCR. Could you run the following command in the console and report here the result?
from contentRecog import uwpOcr;uwpOcr.getLanguages()

[cary-rowen]

Hi @CyrilleB79

Yes I tested with the add-on disabled, but since this machine I can only debug remotely, I just saved this log.
In addition, I also executed the code you provided above when I first checked the problem:
I found that the returned result is "zh-Hans-CN", This seems to be correct, NVDA +R works fine too.

I also found that the implementation of winVersion.isUwpOcrAvailable seems not robust enough.

def isUwpOcrAvailable():
	return os.path.isdir(UWP_OCR_DATA_PATH)

But that might not be directly relevant to the issue.
This will cause problems if the OCR component is corrupted.
Thanks

[hwf1324]

Hi!

Just because your log shows that NVDA is running with add-ons.

This is because @cary-rowen is currently utilizing the NVDA remote add-on to inspect the issue that I have encountered.

Also is there any reason why you are running Windows 10 1809, which is an old release now unsupported by Microsoft?

This is the computer provided by my educational institution for me to use during class.

A convenient approach to reproduce this scenario is to create a folder named OCR in the %windir% directory and then examine the settings dialog, provided that the system is either Windows 7 or a system without OCR capability.

The primary reason I am noticing this issue is because it is resulting in damage to the settings dialog.

Thanks!

[CyrilleB79]

@cary-rowen, when I run the following command
from contentRecog import uwpOcr;uwpOcr.getLanguages()

I get a list (in my case ['en-US', 'fr-FR']).

On your side, you get "zh-Hans-CN", which is only a string value. Could you double check that you have fully copy/pasted the result that you get in the console? Thanks.

[cary-rowen]

@CyrilleB79 wrote:

On your side, you get "zh-Hans-CN", which is only a string value. Could you double check that you have fully copy/pasted the result that you get in the console? Thanks.

Yes, same as you, executing the above code I also get a list, I also suspected at first that the problem was here, but it seems to be correct. I believe @hwf1324 can provide more information on the error

Thank you for your attention

[CyrilleB79]

@CyrilleB79 wrote:

On your side, you get "zh-Hans-CN", which is only a string value. Could you double check that you have fully copy/pasted the result that you get in the console? Thanks.

Yes, same as you, executing the above code I also get a list, I also suspected at first that the problem was here, but it seems to be correct. I believe @hwf1324 can provide more information on the error

Could you provide the full copy of this list please?

[cary-rowen]

Could you provide the full copy of this list please?

If you're referring to the NVDA portable version that reproduces the issue, then no problem, it will be available within 24 hours at the latest.

[CyrilleB79]

Could you provide the full copy of this list please?

If you're referring to the NVDA portable version that reproduces the issue, then no problem, it will be available within 24 hours at the latest.

Not at all! Sorry, we do not seem to understand each other.

I would like you to execute the following command in the Python console of NVDA:
from contentRecog import uwpOcr;uwpOcr.getLanguages()

And then copy the full result that you get, i.e. the square brackets and all the text between them.

For information, this command returns the language codes supported by your system. And I would like to have a look at this exact list of codes.

Thanks.

[hwf1324]

Hi! @CyrilleB79

from contentRecog import uwpOcr;uwpOcr.getLanguages()

>>> from contentRecog import uwpOcr; uwpOcr.getLanguages()
['zh-Hans-CN']

[CyrilleB79]

Hi @hwf1324 or @cary-rowen

Could you please test this build and send me a log?
This should not fix the issue but I hope to gather more information on it.
Thanks.

[cary-rowen]

Hi @CyrilleB79
We investigated this issue in more detail, got some useful information, and will provide a detailed issue report shortly.
cc @hwf1324

Many thanks to @CyrilleB79 for his attention to this issue.

[hwf1324]

After thorough research, it seems that the error might be stemming from the 'LocaleNameToLCID' function in the Win32 API, which is not executing as expected.

Here is an outline of my investigative process:

1. I utilized the 'isUwpOcrAvailable' function to create a new folder titled 'OCR' in the %windir% directory on Windows 7, aiming to reproduce the error. While this did trigger the error, it was not a complete replication. An unhandled exception error was generated:

ERROR - unhandled exception (01:46:18.170) - MainThread (2612):
Traceback (most recent call last):
  File "gui\settingsDialogs.pyc", line 4242, in onCategoryChange
  File "gui\settingsDialogs.pyc", line 689, in onCategoryChange
  File "gui\settingsDialogs.pyc", line 671, in _doCategoryChange
  File "gui\settingsDialogs.pyc", line 599, in _getCategoryPanel
  File "gui\settingsDialogs.pyc", line 357, in __init__
  File "gui\settingsDialogs.pyc", line 367, in _buildGui
  File "gui\settingsDialogs.pyc", line 2627, in makeSettings
  File "contentRecog\uwpOcr.pyc", line 25, in getLanguages
  File "NVDAHelper.pyc", line 634, in getHelperLocalWin10Dll
  File "ctypes\__init__.pyc", line 439, in __getitem__
  File "ctypes\__init__.pyc", line 434, in __getattr__
  File "ctypes\__init__.pyc", line 364, in __init__
OSError: [WinError 126] The specified module could not be found

2. Upon comparison of the two logs, the issue appears to lie in the 'makeSettings' section. A detailed comparison can be found in the following link:
   https://github.com/nvaccess/nvda/blob/3d78d701c4779d25ff7fe0dff5644409d171cc9d/source/gui/settingsDialogs.py#LL2628C3-L2633C101

3. During testing, the list comprehension's result turned out to be 'None'. Therefore, it is plausible that the error arises from the inclusion of a 'None' parameter when adding language descriptions.

4. The investigation led me to the 'LocaleNameToLCID' function call in 'ctypes' which, surprisingly, returned 0. I couldn't identify why this call failed. Microsoft's documentation on this can be found here: https://learn.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-localenametolcid. Notably, the 'Remarks' section suggests a possible deprecation of 'LCID'?

5. I made an attempt to capture the error, but my proficiency in C++ is limited, and my C++ environment is MinGW64. The error code was 0x57, and the output using LOCALE_NAME_* was also odd.

Regrettably, my investigation could only go up to this point. As I am about to leave school, replicating the system environment that caused this error may prove challenging.

That being said, my primary concern lies with the damage to the 'settingsDialogs' GUI interface. It is possible that any unhandled exceptions in 'makeSettings' could be causing this. It might be necessary to conduct some tests to confirm this.

[CyrilleB79]

Thanks for the investigations and the findings that you have reported. The build that I have provided (coming from PR #15031) will not fix the root cause but should fix the GUI issue by handling more robustly the result of the conversion from language code to language name. As a consequence, since your system is not able to convert the language code to a language name, the language code will be listed instead of the language name.

Is this an acceptable workaround for you? I think it's not worth working more on an issue that happens only on a specific system on which Windows is version is not suported anymore.

Regarding LCID deprecation, I do not think that it is the cause given the Windows version is old and given other newer systems have no such issue.

[hwf1324]

@CyrilleB79 Thanks!

I'll test it tomorrow. If the GUI issue can be fixed, then this issue can certainly end here. I'm actually not too concerned about this specific issue, I'm more concerned about more possible GUI corruptions, but until this issue is fixed, everything works fine. And more exception handling would add to the burden.