Windows 10 invisible frame not taken into account when moving to other monitor

[ChrisVanBael]

First I want to say: thank you for updating the source code for the invisible frame on Win10 and the language error at startup!!! Great to have this excellent program working again correct on Windows 10.

For the bug, steps to reproduce:

1. make window half width of 1st monitor on the left side
2. move window to other monitor (with hotkey for move to left/right screen) (right monitor for me) => notice window has a few pixels on the left like the invisible frame in Windows 10 before With the hotkey for Left/Right the border is gone When moving back to the other (left) screen, again the invisible frame on the left is back.

Not a big issue for me, but wanted to let you know.

[dozius]

Thanks for the bug report and steps to reproduce. I think this is likely related to the mixed DPI issue (#5) as well.

Unfortunately, I am still without a second monitor and can't test this. It would be great if someone with a mixed DPI, multi-monitor setup could contribute a patch for these. I don't know if or when I will have the hardware to reproduce and fix these problems.

[langdonx]

I can reproduce (one monitor is vertical).

If you can point me to where in the code the actions occur, and a commit of your last fix to remove the invisible frame, I could make work something out.

I don't write C++, but I do write code. 😅 Shouldn't need anything more than Visual Studio 2019 with the VC++ components, yeah?

[dozius]

@langdonx, thanks for volunteering!

The commit that makes the initial fix is here. The commit message has a link that gives some context.

It's been quite some time since I've looked at this code but I think the best place to start is in functions_resize.h/cpp and multimonitor_move.h/cpp.

I believe I was using Visual Studio 2017 last time I touched this, but I don't see any reason 2019 shouldn't work.

[langdonx]

Hmm, I may not be the guy 😭

• clone repo with --recurse-submodules --remote-submodules
• build wxWidgets per instructions
• build winsplit-revolution per instructions, which fails* (175 errors mostly surrounding wx[Stuff])
• open .sln in VS2019, it asks me to upgrade the solution/project, and then there are 25 errors Cannot open include file 'wx/setup.h': No such file or directory

[dozius]

I haven't tested it, but it's likely the --remote-submodules flag when cloning is the problem. wxWidget releases are tagged commits in master, there is no telling what updating to the latest commit on master will do.

[langdonx]

Hmm, it was on this:

~/desktop/winsplit-revolution/wxWidgets ((156045b73b...))
$ git status
HEAD detached at 156045b73b
nothing to commit, working tree clean

So I:

git checkout 721d62adde3f8ba8704a9cf56efeb050f652dfbf --force
git clean -f -d
git status

And it says:

~/desktop/winsplit-revolution/wxWidgets ((v3.0.4))
$ git status
HEAD detached at 721d62adde
nothing to commit, working tree clean

But I can't build wxWidgets now and don't know enough to over come the issue:

C:\Users\-\Desktop\winsplit-revolution\wxWidgets\build\msw>nmake -f makefile.vc BUILD=release RUNTIME_LIBS=static TARGET_CPU=X64

Microsoft (R) Program Maintenance Utility Version 14.28.29333.0
Copyright (C) Microsoft Corporation.  All rights reserved.

        cl /c /nologo /TC /Fovc_mswu_x64\wxregex_regcomp.obj /MT /DWIN32  /Zi /Fd..\..\lib\vc_x64_lib\wxregexu.pdb   /O2 /D_CRT_SECURE_NO_DEPRECATE=1  /D_CRT_NON_CONFORMING_SWPRINTFS=1 /D_SCL_SECURE_NO_WARNINGS=1  /D__NO_VC_CRTDBG__ /DNDEBUG /D_CRT_SECURE_NO_WARNINGS /I..\..\include  /I..\..\lib\vc_x64_lib\mswu /D__WXMSW__  /D_UNICODE    ..\..\src\regex\regcomp.c
regcomp.c
C:\Users\-\Desktop\winsplit-revolution\wxWidgets\include\wx/msw/chkconf.h(91): fatal error C1189: #error:  "wxUSE_UNICODE_MSLU must be defined."
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.28.29333\bin\HostX64\x64\cl.EXE"' : return code '0x2'
Stop.

[dozius]

Huh, that's new. Apparently it is a config option required to use Unicode on old OS versions. https://wiki.wxwidgets.org/MSLU

It should be defined to 0 in include\wx\msw\setup.h. I suppose this would be the first place to check.

Try a full clean of the submodule directory with git clean -dxf. It looks like that setup file is generated by the build, so maybe you have a stale file from the last build attempt.

For what it's worth, I just did a fresh clone and compiled wxWidgets without issue using the "Developer Command Prompt for VS 2019" shortcut. At least that rules out an incompatibility with VS 2019.

[langdonx]

I wasn't able to get anywhere. I don't want to keep bothering you with troubleshooting it and also just didn't want to leave the thread hanging. I think having VS2019 alone might be the issue.

Ran inside of x64 Native Tools Command Prompt for VS2019 (also tried Developer Command Prompt for VS 2019 but was met with an error saying x86/x64 mismatch).

git clone --recurse-submodules https://github.com/dozius/winsplit-revolution.git
cd winsplit-revolution\wxWidgets\build\msw
nmake -f makefile.vc BUILD=release RUNTIME_LIBS=static TARGET_CPU=X64
cd ..\..\..\
msbuild "Winsplit Revolution.sln" -property:Configuration=Release -property:Platform=x64

Everything succeeds up to building Winsplit, which ends in:

  "C:\Users\-\Desktop\winsplit-revolution\x64\Release\build\winsplit\virtual_key_manager.obj"
wxbase30u.lib(baselib_volume.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4 [C:\Users\-\D
esktop\winsplit-revolution\Winsplit.vcxproj]
wxbase30u.lib(baselib_mimecmn.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4 [C:\Users\-\
Desktop\winsplit-revolution\Winsplit.vcxproj]
...
...
...
wxbase30u.lib(baselib_arrstr.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4 [C:\Users\-\D
esktop\winsplit-revolution\Winsplit.vcxproj]
C:\Users\-\Desktop\winsplit-revolution\x64\Release\Winsplit.exe : fatal error LNK1120: 1 unresolved externals [C
:\Users\-\Desktop\winsplit-revolution\Winsplit.vcxproj]
Done Building Project "C:\Users\-\Desktop\winsplit-revolution\Winsplit.vcxproj" (default targets) -- FAILED.

Done Building Project "C:\Users\-\Desktop\winsplit-revolution\Winsplit.vcxproj.metaproj" (default targets) -- FA
ILED.

Done Building Project "C:\Users\-\Desktop\winsplit-revolution\Winsplit Revolution.sln" (default targets) -- FAIL
ED.


Build FAILED.

"C:\Users\-\Desktop\winsplit-revolution\Winsplit Revolution.sln" (default target) (1) ->
"C:\Users\-\Desktop\winsplit-revolution\Winsplit.vcxproj.metaproj" (default target) (3) ->
"C:\Users\-\Desktop\winsplit-revolution\Winsplit.vcxproj" (default target) (4) ->
(Link target) ->
...
...
...
  wxbase30u.lib(baselib_strvararg.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4 [C:\Users\-\Desktop\winsplit-revolution\Winsplit.vcxproj]
  wxbase30u.lib(baselib_arrstr.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck_EH4 [C:\Users\-
\Desktop\winsplit-revolution\Winsplit.vcxproj]
  C:\Users\-\Desktop\winsplit-revolution\x64\Release\Winsplit.exe : fatal error LNK1120: 1 unresolved externals
[C:\Users\-\Desktop\winsplit-revolution\Winsplit.vcxproj]

    0 Warning(s)
    248 Error(s)

When I open the .sln, I'm always prompted with:

If I choose No Upgrade from both drop downs, the solution won't open, so I'm forced to make a choice. When I do make a choice (default/latest), it says it can't find wx/setup.h on platform.h:183. Makes me think wxWidgets didn't build correctly.

Don't feel compelled to continue helping troubleshoot. ;)

[dozius]

Yeah, the projects would need to be updated for 2019 by opening them in VS2019 first. I should have mentioned that.

The automatic re-targeting & upgrade should work, it works here. It seems like it's missing some include paths. I noticed there are a bunch of old configurations still left in the project files, it could be VS is defaulting to some target that I never build against that isn't setup correctly.

One thing to try would be to open the solution in VS2019, retarget, upgrade and save. Then try a clean build from the command line again to ensure the correct configuration is being built.

If that still isn't working, then I will try to find a bit of time to cleanup and update the project files for VS2019 which should hopefully fix any issues.

Thanks for the effort!

[dougkulak]

Just wanted to say that I followed the instructions in this thread on Windows 10 and was able to get it compiled and working with VS 2019. There were some errors regarding LC_NUMERIC and runtime_error not being a member of 'std', but it didn't seem too important for what I needed so I just commented the offending lines out and had a successful build.

Hoping this might help others. The program works great, by the way. It's so nice to have Winsplit back again!

@dozius If you get time, updating the repo with the files working out of the box for VS2019 (or even 2022) would be awesome!