Menu
▾
▴
2 Attachments
#215 Bug when resizing the SyncTERM window
Hello! If you resize the SyncTERM window using the mouse in the upper left corner, you'll notice that it displays incorrectly; specifically, the window takes on the classic (old) style. This can be seen in the video. The attached image shows a still from the video showing the window in the classic (old) style. SyncTERM for Win64 recompiled Fri Jan 02 2026 08:04:40, from http://www.syncterm.net
Discussion
Anonymous
This pretty much has to be a Windows issue... SyncTERM simply calls
SetWindowPos()withSWP_NOMOVE|SWP_NOOWNERZORDER|SWP_NOZORDERin response to aWM_SIZEevent to keep the same aspect ratio.SyncTERM has no idea what the old and new window decorations look like, isn't requesting either one, and certainly isn't drawing them.
If I resize the window with the mouse in the lower right corner, this bug doesn't occur. Is it possible that the bug exists in one corner of the window and not in another?
SyncTERM doesn't pay any attention to which corner or side is dragged... it just takes the new size that Windows gives it, adjusts it to be the correct aspect ration, then asks Windows to change the size to the aspect ratio corrected size. It appears that Windows may be trying to keep the vertical size unchanged or something. I'll dig around a bit in exactly what's happening there.
So, as far as the API calls are concerned, it looks like SyncTERM is doing "the right thing", but Windows appears to be getting confused because when dragging any corner other than the bottom-right, if the window size changes, the window position may also change.
It looks like Windows is not keeping the window position the same, which results in it "shuddering" between new and old locations before "locking in" once dragging stops. I don't think the notification actually gives me the current position though, but I'll see what's possible.
Ok, I've made a change that may address this... it changes how the sizing rectangle is adjusted. On my system it seems to make the resizing from all eight handles better, but I'm not sure if it actually "fixes" the issue or not (on my system the effect is too fast to really see).
I did a rebuild on the version on syncterm.net, so you should be able to test it now.
Excellent, this bug is fixed, thank you!