@FanaticGuru
Yeah i understand that it happens for a reason, my guess is that they chose this jittering instead of resizing of the window being "slower" like, i think there is a way to... it's kinda hard to explain but bare with me, when user drags to resize the window, the window wouldn't immediately snap to the mouse position, instead it would calculate the desired positions of controls inside the window, it would place them accordingly (without repainting the window) and only THEN the actual window would get resized. (I've explained it pretty badly but hopefully it's understandable...)
The more technical explanation:
as the thread i posted states -
During the processing of those messages (shortly after WM_WINDOWPOSCHANGING returns), Windows makes an internal call to SetWindowPos() to actually resize the window. That SetWindowPos() call first resizes the non-client area (e.g. the title bars and window border) then turns its attention to the client area (the main part of the window that you are responsible for).
So, is it technically possible to "sync" the
client area resizing with the
non-client area resizing?
(or perhaps, delay the non-client area resizing)
I personally would probably never find a "nice" solution, the most i could muster would be some wonky work-around.
Now i'll bore you with some things i've messed around with:
Let's take the first code i posted ~
Code: Select all
#SingleInstance, Force
Gui, +Resize
Gui, Color, Black
Gui, Add, Edit, w400 h200 vEditField
Gui, Show
Return
GuiSize:
GuiControl, Move, EditField, % "w" A_GuiWidth-20 " h" A_GuiHeight-10
Return
it behaves (FOR ME) like this
But for some odd reason, this ~
Code: Select all
#SingleInstance, Force
Gui, +Resize
Gui, Color, Black
Gui, Add, Edit, w400 h200 vEditField +hwndEditFieldHwnd
WinSet, Transparent, 255, ahk_id %EditFieldHwnd%
Gui, Show
Return
GuiSize:
GuiControl, Move, EditField, % "w" A_GuiWidth-20 " h" A_GuiHeight-10
Return
(added WinSet, Transparent, 255, ahk_id %EditFieldHwnd%)
looks like this
In my personal opinion, the second way looks better.
And here's a funny find ~
Code: Select all
#SingleInstance, Force
Gui, +AlwaysOnTop +Resize
Gui, Color, ffffff
Gui, Add, StatusBar, +hwndSBHwnd -Theme -0x400000
SendMessage, 0x408, 100, 0,, ahk_id %SBHwnd% ; Change status bar height.
Gui, Add, Progress, x0 y0 w10000 h102 +hwndPHwnd +Backgroundblue ; A wonky solution to get a solid color for the statusbar.
DllCall("SetParent", Ptr, PHwnd, Ptr, SBHwnd) ; SetParent progress to statusbar.
Gui, Add, Button, x5 y5 h30 +hwndBHwnd vButtonLabel, Hello!
DllCall("SetParent", Ptr, BHwnd, Ptr, PHwnd) ; SetParent button to progress.
WinSet, Transparent, 255, ahk_id %SBHwnd% ; For some odd reason, this causes the statusbar to not jump around nearly as much.
Gui, Show, w500 h500
Return
GuiSize:
GuiControl, Move, ButtonLabel, % "w" A_GuiWidth-10 ; Move button
Return
I've commented most stuff, again it uses the
WinSet, Transparent weirdness but this time with a statusbar.
it looks like this
And if the statusbar is right-justified or whatever, the jittering/jumping stops horizontally instead of vertically.
Keep in mind that the gif's don't 100% represent how it looks for me in person, in person there's much more jittering/jumping
EXCEPT the statusbar method, it's almost as smooth as the gif, there's no "jittering" but it rarely "jumps"
Anyways i just posted these for fun, they're not real solutions to this problem because for my friend (with the better pc), the statusbar method is insanely jittery/jumpy and the statusbar sometimes even pokes out the bottom of the window when it jumps so yeah
I realize there's not much of a point me posting the code and stuff since not many people can test it out because again, only "worse pc's" have this problem but i like messing around with this kind of stuff
![Razz :P](./images/smilies/icon_razz.gif)