You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With Per Monitor V2 DPI Scaling, the showingHandler code in TouchKeyboardNotifier does not return the correct occludedRect when the window which raised the event is on a non-primary monitor and that monitor's DPI scaling is different to the primary monitor's. It seems that the returned value assumes that it is coming from the primary monitor when it may not be. This issue may be in the underlying InputPane class this sample uses as it seems like that might be returning the incorrect values based on my investigation.
Note that this was tested with Per Monitor V2 Scaling enabled in the app manifest of a WPF app using both .Net Framework 4.8 and .Net Core 3.1. The WPF window itself scales fine and doesn't use bitmap stretching, but the occludedRect value produced in the showingHandler from this sample returns values that are too small or too big when the window which raised the event is on a non-primary monitor and that monitor's DPI scaling is different to the primary monitor's. When the WPF window is on a primary monitor, it seems to work fine regardless of DPI scaling.
Here is the expected behaviour (When WPF window is on a primary monitor):
And here it is on a secondary monitor whose DPI scaling is different from the primary monitors. The occludedRect is far to tall, resulting in most of the window being cut off when the content within it is resized to fit within the top of the touch keyboard and the top of the screen:
This was using Windows 11 but the issue occurs in Windows 10 too.
The text was updated successfully, but these errors were encountered:
With Per Monitor V2 DPI Scaling, the showingHandler code in TouchKeyboardNotifier does not return the correct occludedRect when the window which raised the event is on a non-primary monitor and that monitor's DPI scaling is different to the primary monitor's. It seems that the returned value assumes that it is coming from the primary monitor when it may not be. This issue may be in the underlying InputPane class this sample uses as it seems like that might be returning the incorrect values based on my investigation.
Note that this was tested with Per Monitor V2 Scaling enabled in the app manifest of a WPF app using both .Net Framework 4.8 and .Net Core 3.1. The WPF window itself scales fine and doesn't use bitmap stretching, but the occludedRect value produced in the showingHandler from this sample returns values that are too small or too big when the window which raised the event is on a non-primary monitor and that monitor's DPI scaling is different to the primary monitor's. When the WPF window is on a primary monitor, it seems to work fine regardless of DPI scaling.
Here is the expected behaviour (When WPF window is on a primary monitor):
And here it is on a secondary monitor whose DPI scaling is different from the primary monitors. The occludedRect is far to tall, resulting in most of the window being cut off when the content within it is resized to fit within the top of the touch keyboard and the top of the screen:
This was using Windows 11 but the issue occurs in Windows 10 too.
The text was updated successfully, but these errors were encountered: