While EnableVisualStyles is false, MonthCalendar HitTest() does not return a valid HitTestInfo when clicking anywhere on the control.
.NET version
Tested in current versions: .NET8, .NET9 and .NET10, and the issue exists in all versions.
Did it work in .NET Framework?
Yes
Did it work in any of the earlier releases of .NET Core or .NET 5+?
Issue exists in older versions (.NET5) as well.
Issue description
While EnableVisualStyles is set to false, MonthCalendar HitTest() does not return a valid HitTestInfo when clicking any of the valid areas on the control. It always returns a HitArea of Nowhere. This exact scenario works fine in .NET Framework, and it works correctly if EnableVisualStyles is true.
Steps to reproduce
Steps:
- Run the attached sample.
- Click anywhere on the MonthCalendar.
Results: The listbox shows displays the Point and HitArea which is always "Nowhere"
In modern .NET WinForms, MonthCalendar.HitTest() is implemented per the Win32 specification of MCM_HITTEST and MCHITTESTINFO. That specification requires the caller to pass the full MCHITTESTINFO structure (including SYSTEMTIME) and set cbSize to the exact size of that structure, PR https://github.com/dotnet/winforms/pull/2090 did this change . When visual styles are disabled, the control falls back to the classic Common Controls path. On that path, the larger v6 structure size is not recognized, the native hit test returns MCHT_NOWHERE, and the managed wrapper maps it to HitArea.Nowhere. In contrast, .NET Framework retained legacy tolerance for the classic path and could still return a valid hit area. This is by design in modern .NET and not a regression.
Recommended resolution: Enable visual styles (Application.EnableVisualStyles()) so the control runs on the supported v6 path and HitTest() returns valid results.
Please refer to: https://learn.microsoft.com/en-us/windows/win32/controls/cookbook-overview https://learn.microsoft.com/en-us/windows/win32/controls/mcm-hittest https://learn.microsoft.com/en-us/windows/win32/api/commctrl/ns-commctrl-mchittestinfo
It would have been nice to maintain legacy tolerance for the classic path like in .NET Framework, but I understand the goal to minimize bloat in the modern frameworks. Unfortunately, as a component developer, we don't have control over the enabling of visual styles by the application developer. The best we can do is reenforce that modern .NET platforms expect the use of modern styling.