NVDA: ComboBox Selected Item Not Announced in DropDownList Style in .NET Framework 4.8 WinForms Applications

[cary-rowen]

This issue describes behavior that is the opposite of the issue mentioned in dotnet/winforms issue #8395, where the selected item was announced when the ComboBox style was set to DropDown, but not when set to DropDownList. This issue has been addressed and fixed by the PR in dotnet/winforms PR #8396, which corrected the behavior to ensure that the selected item is announced in both styles.

Given that .NET Framework 4.8 is the last version supporting WinForms, and a significant number of WinForms applications rely on .NET Framework 4.8, I strongly recommend that NVDA addresses and fixes this behavior to ensure compatibility and consistent user experience for these applications.

Steps to reproduce:

1. Download the provided project files.
2. Run the project and click "Change style" button and observe the behavior of the ComboBox.
3. Press the Down Arrow key.

Actual behavior:

The currently selected item is not announced when pressing the Down Arrow key in the ComboBox, even when the ComboBox style is set to "DropDownList."

Expected behavior:

NVDA should announce the currently selected item when the Down Arrow key is pressed, regardless of whether the ComboBox style is "DropDown" or "DropDownList."

NVDA logs, crash dumps and other attachments:

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2024.4.1

Windows version:

Windows 10 22H2 (AMD64) build 19045.5131

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

.net Framework4.8

Other information about your system:

n/a

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.

NVDA Alpha can also reproduce

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

[cary-rowen]

@Adriani90
Is there already an issue? I searched before creating this issue but found nothing.

[Adriani90]

No I didn't find one either yet.

[cary-rowen]

cc @SaschaCowley
@gerald-hartig

[seanbudd]

Just to confirm, this has already been fixed in WinForms? Is this issue requesting us to fix this in older versions in WinForms? It's unclear what the remaining work is

[cary-rowen]

Hi @seanbudd

As far as I know, .netFramework4.8 is the last .netFramework version. The new version of .net does not have this problem.
However, .NetFramework4.8.1 seems to only provide security updates, and Microsoft will most likely not provide a fix for this.
https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-framework

[seanbudd]

Thanks for explaining @cary-rowen . Closing as won't fix. We don't support legacy software like this, and Microsoft has fixed it in their supported software.

[cary-rowen]

cc @seanbudd

The new version is .net but not .netFramework. There are many softwares that cannot be migrated from winForm supported by .netFramework to wpf.

.netFramework has not been abandoned by Microsoft, which means that software based on .netFramework is still popular.

[Adriani90]

I agree with @cary-rowen , as long as Windows still supports applications created in .net framework, and NVDA still supports Windows 8.1 and Windows 10, there is no reason yet to end support for this particular framework. Reopening.

[seanbudd]

@cary-rowen you mention here:

However, .NetFramework4.8.1 seems to only provide security updates, and Microsoft will most likely not provide a fix for this.

This implies that it is no longer under active support. Other additional material that I have read confirms this.
For issues that need to be fixed externally, we close them when they have been fixed in the supported software.
This issue needs to be fixed by Microsoft in netFramework. If the framework is no longer receiving support than there's nothing to be done.

[josephsl]

Hi, I think we also need to take .net apps into account as not all apps were migrated to newer .net releases. Therefore, if the later .net releases fixes it, then we might as well contact developers of affected apps in hopes of asking them to use newer technologies if possible. Thanks.

[cary-rowen]

I have to make a point:
Software/tools used by visually impaired users are more likely to be broken and it is more difficult to find equivalent replacements.

I opened this issue because a user contacted me and said that the software he uses to run his store every day is a Winform application developed by .netFramework, and the developer of the application has lost the source code, which means that the software cannot be obtained at all. Maintenance, migration to a new framework is even less possible.
Trying to find an equivalent replacement with good accessibility in a short period of time is not an easy task.
There may be many examples like this.

This is just one example, but I hope it makes us think more.