Location 0, 0 not working on windows 10

[thanhhn253]

Steps:

• Create new windows form app
• Set StartPosition = Manual
• Set Location = 0, 0
• Run the app
• The app does not display at 0, 0

Please fix!

[thanhhn253]

And if you set Height = Screen.FromHandle(Handle).WorkingArea.Height; it will leave some space at the bottom

[RussKie]

Please provide a sample app and screenshots.

[thanhhn253]

Sample app: https://github.com/thanhhn253/test/raw/master/issues_4776.zip
Screenshot:

[mcsilver]

Hi, what's the status of this one for WinForms and .NET Framework 4.7.2, please? I'm noticing the same thing.

[dreddy-work]

This is something that may need to address with Operating System. Other native tools show this window is actually located at 0,0 and that make me think drawing of the window is off here. @mcsilver , did you try with a native (MFC) application?

@Olina-Zhang can you check this with native app?

[mcsilver]

Hi @dreddy-work, this may be a problem of understanding more than a problem with the software. In your screenshot, I see that the window's position shows in WinSpy++ as (0,0) but its location on the screen does not appear to be against the left edge of the screen, in my opinion, whereas its top is. Why would its left edge not be touching the edge of the screen when its location is (0,0) whereas its top edge is?

[Olina-Zhang]

@Olina-Zhang can you check this with native app?

@dreddy-work MFC native dialog- application has the same testing result:

[RussKie]

If an MFC app is exhibiting this behaviour, then this is likely a Windows level bug.

[mcsilver]

Crazy! Okay, thanks.

[dreddy-work]

Opened an internal bug in Windows repo and will be tracking the issue there. @mcsilver , to track the progress publicly, you may want to open a feedback ticket for Windows operating system via one of the channels defined here

[mcsilver]

That's great, @dreddy-work. I took your suggestion.

[RussKie]

Out of curiosity, does a WPF app exhibit the same?

[Olina-Zhang]

Out of curiosity, does a WPF app exhibit the same?

Yes, it is same.

[dreddy-work]

Response from OS team for reference:

This behavior is by design (oddly enough). In Windows 10 the design was changed so that window borders would have thin (1px at 96 DPI) borders.

Literally switching to 1px of non-client area on the edges wouldn't work out because grabbing the edges with the mouse would be too hard. So, the amount of non-client space on the edges was left as 8px wide, but 7px of that space is now transparent. The programmatic edge of the window is now in a different position than the visible edge of the window.

That is case on the sides and bottom of the window, but wasn't necessary on the top edge.

Apps can query the amount of this transparent space with DwmGetWindowAttribute + DWMWA_EXTENDED_FRAME_BOUNDS. But note that that API is NOT DPI virtualized, and will return raw physical pixels regardless of the DPI awareness mode of the caller. That means that it will work fine for per-monitor-aware apps, but will return confusing answers to unaware or system-aware apps.

You can indirectly see this behavior with winspy. The red selection overlay thing is the positioned around the true window bounds (aka GetWindowRect), but you can see on the sides and bottom that the visible border is inset quite a bit from that.

You will also notice that the mouse cursor changes to the resize cursor outside the windows border.

Image

Image

@mcsilver and @thanhhn253 as FYI.

[mcsilver]

Hi Devendar, I wondered if it was something like that. In fact, I have often been frustrated by the lack of border width when attempting to resize from the top. A question though: After I manually drag a window’s left edge to the left edge of the screen, it seems that the cursor still has several pixels within which it switches to the resizing state. In other words, it doesn’t appear to be a problem for Windows to: 1) position a window against the left edge when it is programmatically set to (0,0), and 2) give the top border the same 8px width, allowing the user to position the cursor more easily for resizing from the top. Am I missing something, or could these changes be implemented without ill effect?

[dreddy-work]

Am I missing something, or could these changes be implemented without ill effect?

This is the windows decision based on feedback they received. Windows team/feedback channel might be the best place to chat further on this.

[thanhhn253]

So now we need to set Location: (-7, 0) right?
Is it always 7px or it depend on the monitor resolution?
Can you provide C# code to get the transparent space width?

Sorry for the late response!

[RussKie]

As per the Windows team response posted above:

Apps can query the amount of this transparent space with DwmGetWindowAttribute + DWMWA_EXTENDED_FRAME_BOUNDS. But note that that API is NOT DPI virtualized, and will return raw physical pixels regardless of the DPI awareness mode of the caller. That means that it will work fine for per-monitor-aware apps, but will return confusing answers to unaware or system-aware apps.

Windows Forms SDK will not be providing API for this.

[mcsilver]

Fair enough. From: Devendar Reddy Adulla ***@***.***> Sent: Monday, August 29, 2022 11:11 AM To: dotnet/winforms ***@***.***> Cc: Craig ***@***.***>; Mention ***@***.***> Subject: Re: [dotnet/winforms] Location 0, 0 not working on windows 10 (#4776) Am I missing something, or could these changes be implemented without ill effect? This is the windows decision based on feedback they received. Windows team/feedback channel might be the best place to chat further on this. — Reply to this email directly, view it on GitHub <#4776 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAU6WWDNAVLDPLLV7PP5QZ3V3T4LDANCNFSM42YOJAKQ> . You are receiving this because you were mentioned. <https://github.com/notifications/beacon/AAU6WWDADARNTLQ7IWFJDSTV3T4LDA5CNFSM42YOJAK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOJFNK2IY.gif> Message ID: ***@***.*** ***@***.***> >