Discussion:
WS_BORDER interference on SC_DRAGMOVE - how to fix ?
(too old to reply)
R.Wieser
2023-01-06 11:21:55 UTC
Permalink
Hello all,

I'm dragging and/or resizing individual controls by sending them a
SC_DRAGMOVE family message. That works.

The problem is that when I give the control a WS_BORDER attribute (causing a
black, single-pixel wide border to be drawn) than a number of the basic
controls (static, edit, others) get a forced minimum size (which does seem
to match the minimum width and height of a dialog).

Question : Can, and if so how do I tell the move/size executing code *not*
to apply those minimum size contraints ?

Regards,
Rudy Wieser
Paul N
2023-01-06 16:24:44 UTC
Permalink
Post by R.Wieser
Hello all,
I'm dragging and/or resizing individual controls by sending them a
SC_DRAGMOVE family message. That works.
The problem is that when I give the control a WS_BORDER attribute (causing a
black, single-pixel wide border to be drawn) than a number of the basic
controls (static, edit, others) get a forced minimum size (which does seem
to match the minimum width and height of a dialog).
Question : Can, and if so how do I tell the move/size executing code *not*
to apply those minimum size contraints ?
Can you intercept the WM_GETMINMAXINFO message? As far as I can tell, Windows sends this to a window as part of its check that a proposed new window size is actually OK, you just need to grab this message and "reply" saying that the current size of the window is indeed OK so there's no need for Windows to apply an unwanted default.
R.Wieser
2023-01-06 17:12:09 UTC
Permalink
Post by Paul N
Can you intercept the WM_GETMINMAXINFO message?
Yep. And you hit the nail on the head. :-) Just setting the
mintrackposition_x and -y members to someting small does the trick.

Its a bit stupid though, I have put the handling of that message into my
"framework" program for a new dialog, but simply didn't think about it. :-|

Thanks.

Regards,
Rudy Wieser

Loading...