AppWindow.Position, AppWindow.Move, and AppWindow.TitleBar.Height all are faulty and give wrong results. AppWindow.TitleBar.Title does not show up in Window (simple repro project included) #17679
Labels
area-controls-window
Window
platform/windows 🪟
s/triaged
Issue has been reviewed
s/verified
Verified / Reproducible Issue ready for Engineering Triage
t/bug
Something isn't working
t/desktop
The issue relates to desktop scenarios (MacOS/MacCatalyst/Windows/WinUI/WinAppSDK)
Milestone
Description
It is useful in UWP to be able to manage your own click events as if one uses an overlay (eg. similar to built in
WindowOverlay
) to catch clicks, there is no way to selectively pass those clicks on to objects that you wish to handle their own clicks for (like to text fields). Once an overlay catches the click it is "consumed" and it seems there is no way to create a new cloned event and introduce it into another part of the hierarchy.It would be nice if we had some way to manually put in click events to parts of the hierarchy in UWP. Like in Android, we have
Android.Views.View.DispatchTouchEvent(MotionEvent)
. In iOS we can build an overlay and override Hit Detection to select the View to take our clicks which accomplishes the same. But no similar function seems available in UWP (?).Until such function is available, we must be able to get our clicks in Windows another way to not disrupt the natural function of complex objects underneath.
To gain access to the raw Windows clicks, one can use a package like SharpHook:
https://github.com/TolikPylypchuk/SharpHook
https://www.nuget.org/packages/SharpHook/
This integrates well but cannot provide accurate results as Maui has several glitches in getting window data:
Microsoft.UI.Windowing.AppWindow.Move
andMicrosoft.UI.Windowing.AppWindow.Position
both are off target in the x-dimension by a certain amount.Microsoft.UI.Windowing.AppWindow.TitleBar.Height
returns zero always.Microsoft.UI.Windowing.AppWindow.TitleBar.Title
to any string does not actually change the Window title.We need these glitches fixed in order to get accurate relative positions otherwise by the mouse hook. Given point #3, I suspect there is some disconnection in the internal wiring and we are not reaching the
TitleBar
at all.Steps to Reproduce
Reproduction Steps:
Create a new Maui file in Visual Studio 2022 using .NET 7.0 named "Windows Window Position Bug"
Add nuget package for SharpHook: https://www.nuget.org/packages/SharpHook/
Copy/paste to replace
App.xaml.cs
with the following code:This should initialize the app with the window at screen (0,0), and while the app will claim to have done so, it will actually have a left screen gap (setting x position to 0 does not put screen aligned with zero left position).
AppWindow.TitleBar.Height will debug out on clicking as zero height, so one cannot subtract the height of the title bar from raw click positions to get the true "in app" window click position.
Clicking anywhere on screen should put the red ring around your cursor, but the position will be off by the x-deviation of the left window gap, and the y-deviation of the height of the title bar.
The window title should be set to "WINDOW TITLE" and it will show this in the status bar. However, the title bar itself will still have no name showing.
What Should Happen:
App.Window.TitleBar.Height
should return the height of the grey title bar (top application bar with the maximize minimize buttons) so we can compensate for it with the click position.AppWindow.Position.Move
to (0,0) should put the window perfectly aligned to x=0, y=0 soAppWindow.Position
returns accurateX
&Y
results at any given window position.App.Window.Title
should show up in the title bar and not just the status barLink to public reproduction project repository
https://github.com/jonmdev/Windows-Window-Position-Bug
Version with bug
10.0.92
Is this a regression from previous behavior?
Not sure, did not test other versions
Last version that worked well
Unknown/Other
Affected platforms
Windows
Affected platform versions
Windows 10/11, .NET 7.0, .NET 8.0
Did you find any workaround?
No workaround except manually guessing or estimating size of x-gap and expected height of title bar and compensating accordingly.
Relevant log output
See above
The text was updated successfully, but these errors were encountered: