Implementing HeadingLevel and IsDialog automation properties

[guimafelipe]

Fixes Issue #1825

Description

The HeadingLevel property was not implemented in WPF yet. This PR implements this property.
The IsDialog property was algo not implemented. This PR implements this property.

Customer Impact

Customers will now be able to set the HeadingLevel and the isDialog automation properties in WPF projects.

Regression

No regression.

Testing

Manually tested

[dnfadmin]

All CLA requirements met.

[ThomasGoulet73]

You need to implement this method in native code for this to work:

You can add it here:

wpf/src/Microsoft.DotNet.Wpf/src/Shared/OSVersionHelper/osversionhelper.cpp

Line 132 in 53bfa05

And set _RS4_BUILD_NUMBER to 17134 here:

wpf/src/Microsoft.DotNet.Wpf/src/Shared/OSVersionHelper/wpfsdkddkver.h

Line 14 in 53bfa05

#define _RS3_BUILD_NUMBER 16299

[ryalanms]

Thanks, @ThomasGoulet73. IsWindows10RS4OrGreater and the others are implemented in PresentationNative, which is in a separate internal WPF repo.

[ThomasGoulet73]

Thank you @ryalanms! I didn't know that the PresentationNative is closed source and that the project in this repo is simply a redist. Is it planned to open-source PresentationNative or is the status still the same as #2554 ?

[vatsan-madhavan]

There is a historical reason why IsWindows10RS4OrGreater etc are sitting in PresentationNative. It should be possible to move these to an open source assembly (esp to minimize the footprint of closed-source where possible) without problems.

When we originally added these years ago (circa .NET 4.6.1 probably), the only way to do reliable OS version checks was by calling RtlVerifyVersionInfo API’s - VerifyVersionInfo didn’t work well and it required application manifests which was not feasible from a DLL. RtlVerifyVersionInfo at that time was only documented as being available via NtosKrnl.lib - the ntdll.dll export was well known but hadn’t been officially documented at that time (on MSDN/docs.Microsoft.com). So instead of just P/Invoking into RtlVerifyVersionInfo, we linked PresentationNative to NtosKrnl.lib to get access to RtlVerifyVersionInfo and exported our own functions from there to P/Invoke into (remember, .NET and thus WPF only uses documented API’s).

Forward a few years RtlVerifyVersionInfo was documented as a dual mode API exported out of ntdll.dll (and NtosKrnl.exe) and this complicated way of consuming that API was no longer needed (now instead of linking to NtosKrnl.lib, we could P/Invoke into ntdll.dll if that’s what we preferred) - but we never changed the approach.

[ryalanms]

@guimafelipe: Sam has signed off. Can you squash and merge?

[vedeevi]

Hi All,

Please let us know when will this Accessibility Header Level feature will be released to PresentationFramework to integrate with our WPF XAML application as we are getting complaints from Accessibility assessment teams and also from Accessibility challenged users.

Thanks,
vedeevi.

[ThomasGoulet73]

Hey @vedeevi, this was added in .Net 6.0.0-preview.7 and I have validated that the added apis do exist on my machine which has .Net 6.0.1 installed. To my knowledge, this has not been added to .Net Framework so it requires .Net 6 (Though someone from the WPF team might want to correct me).

[SamBent]

That's correct. .NET 6 has the new apis. On the .NET Framework side, the plan is to include them in the next release (.NET 4.8.1).