Windows OS ::getDesktopMode() fix

[Hydra]

...
While the window borders shrunk to 1 pixel thickness in Windows 10, Microsoft kept the old "thick borders"  behind the scenes for easier resizing.

Here you can see it in action:



As you can see, from the top, the cursor changes as the cursor touches the actual window.

But from the left, the cursor changes quite a bit earlier. This invisible part of the border is what causes that "gap" when displaying the windowed full screen with borders.
...

just thought that was very interesting 

...Also it clearly doesn't change with themes because I have a theme installed and it doesn't change.

but just because it doesn't change with the theme you're using does that guarantee that it won't be affected by ANY theme ?

and I think his point still stands

what if MS decides to change border width on the next windows 10 update ?
or what if it makes the border visible ?

Themes don't affect it. They simply change icons and colors. Also as I said in my original post there is a more dynamic solution which is using <window.h> to get the border width. Which would mean even if it changed you would be able to get the correct width.

[binary1248]

I wonder why nobody has suggested just maximizing the window...

Obviously, with the current SFML API, there is no way of saying "give me a window whose outer extents match x,y". So instead of saying give me a window that is the same size as the desktop resolution, just maximize the window right after you create it. That is what you really want in the end anyway. The desktop resolution video mode should only really have to be used for fullscreen or positioning the window somehow, but not for creating floating windows, else you will end up with the problem described in this thread.

Since SFML doesn't support programmatically maximizing the window, you will have to use the Windows API for this:

ShowWindow(window.getSystemHandle(), SW_MAXIMIZE);

Don't forget to include <windows.h>.

[Mario]

Themes don't affect it. They simply change icons and colors. Also as I said in my original post there is a more dynamic solution which is using <window.h> to get the border width. Which would mean even if it changed you would be able to get the correct width.

Unfortunately it's not that easy either. There's a visible discrepancy between the actual border width (didn't try it, but I'm sure it's reported as either 0 or 1) and the visible border we've noticed.

I thought about adding a small patch to re-center the window horizontally in case it's bigger than the desktop, but I guess this would screw up multi-screen setups (which I can't test right now due to lack of desktop space).

[Hydra]

Themes don't affect it. They simply change icons and colors. Also as I said in my original post there is a more dynamic solution which is using <window.h> to get the border width. Which would mean even if it changed you would be able to get the correct width.

Unfortunately it's not that easy either. There's a visible discrepancy between the actual border width (didn't try it, but I'm sure it's reported as either 0 or 1) and the visible border we've noticed.

I thought about adding a small patch to re-center the window horizontally in case it's bigger than the desktop, but I guess this would screw up multi-screen setups (which I can't test right now due to lack of desktop space).

Yeah, but for me even if I change border width the code I supplied works with that solution?

[Jesper Juhl]

with the current SFML API, there is no way of saying "give me a window whose outer extents match x,y". So instead of saying give me a window that is the same size as the desktop resolution, just maximize the window right after you create it. That is what you really want in the end anyway

So maybe SFML should provide that (fullscreen option)? Sounds like a useful addition to me.
I want a window that covers the entire screen at the current resolution - that seems like a reasonable (and useful) thing to ask for.

[Satus]

... just maximize the window right after you create it ...

Correct me if I'm wrong, but if the size of the window is bigger or equals to the size of the screen, then when you maximize it, the objects inside will be slightly but noticeably resided.

[Hydra]

I don't mean to revive an old topic but does anyone actually know why Microsoft made it so the Windows window borders are bigger? It's a little weird how it's only on the sides.

[Mario]

Revive? The topic is still pretty "recent".

As mentioned above, I guess it's to easy resizing/grabbing the edge, considering 1 pixel is really narrow (a lot thinner compared to previous versions of Windows), especially considering Windows 10 wants to allow you to use touch as well.

You don't need that precision for the title bar, since that's a lot bigger anyway.