WM_RESIZE - Can Capture in Parent ?

[shiggsy]

Hi,
I have some child Windows on a view. These are dynamically created in the Views onCreate. I now need to make these child wnds resizeable and handle that but without altering the child windows code.

I can add WS_THICKLINE to the create statements in the view to make them resizeable. I know I can capture the WM_RESIZE msg in each child window and handle it there, but i would rather have the parent capture and handle it for each respective window. Is there a way I can do this, or do I have to capture it in the child and notify the parent ?


Many thanks

[astanley]

There is a whole section on this web site for Resizable Dialogs.

[shiggsy]

Hi,
it's not the parent/dialog/view that I am re-sizing these are staying static, it is one of the child windows where I click on the child window border and resize it with the mouse. I want to capture the resize messages in the parent window, if this is possible. Do the resize messages actually goto the parent as well ?

I did already look in the area you pointed out, if the answer is still in there could you name the link as I am missing it.

Thanks

[shiggsy]

Duh sorry,
I ment WM_SIZING not WM_RESIZE

[JohnCz]

I am not sure what are you trying to do.
Parent window does not receive specific message about child being resized.

One thing that comes to my mind is that while resizing child of the view, view will receive WM_ERASEBKGND message to determine what window is being resized by comparing window rectangle with clipping box rectangle.

[VladimirF]

Unfortunately, you would only get WM_ERASEBACKGROUND if you reduce the size of the child window...
Usually, parent windows are responsible for moving / sizing their child windows, not the other way around.
If you think about it, how is the parent window affected when the size of the child window changes? At most, some area will get uncovered.
I think your best bet would be to send a generic notification to a parent that some size has changed, and let it figure the rest.

[JohnCz]

Originally posted by VladimirF
Unfortunately, you would only get WM_ERASEBACKGROUND if you reduce the size of the child window...

Hmmm, what makes you say that? If window change size (either way), background has to be erased to allow painting of other windows – covered or uncovered.
The same holds true if child window is resized.
Just build a test app and check for youself.

[VladimirF]

Originally posted by JohnCz
Hmmm, what makes you say that?

Hunch? Reasonable guess? If the size of the child window increases, there are no new (uncovered) areas of the parent that require re-painting.
However, I did build a test app that shows that WM_ERASEBACKGROUND in fact is sent to the parent (you got a point), but the clip rectangle is set to (0,0,0,0) (I got one too - NOTHING to erase).
For anyone interested, I've attached the test project. Just watch traces in the output window while you resize the child button up and down.

[JohnCz]

VladimirF, are you being unreasonable, or you always do that creating children of the view?
I mean you have changed style of the view adding WS_CLIPCHILDREN. That is not default style for a view. And that is the only reason clip box returns empty rectangle.

If you remove this style you will get what I described.

We have to have common base to make discussion valid by making sure that we are talking about the same things. If you change default we would talk about two different things.

For anyone interested. Just watch traces in the output window while you resize the child button up and down after removing cs.style |= WS_CLIPCHILDREN from CResizeChildView::PreCreateWindow.

[shiggsy]

HI guys,
thanks for the responses. I can see now that the WM_SIZING message is associated with the window being resized only. Thats the info I was after.

If your bored this it what i'm doing :

imagine a window with 4 evenly sized square child controls in it 2 up 2 down.
|------|
| [] [] |
| [] [] |
|------|

Currently the two left ctrls and the bottom right size themselves proportionaly to each other and there own font sizes along with the parent window when it resizes. The top right control sizes itself last to the remaining space left to it. This is fine.

If the user though decides they would prefer one window bigger and another smaller then they can now drag one of the window s bigger with the mouse, and as it is resized the other controls move out of its way to a fixed minimum size. This currently all works fine through a small class based in the parent window, but to notify it something is going on I have to make sure each control send it a WM_SIZING msg, ie changing the Child Control's Code.

If i could have got away with getting the childs WM_RESIZE msg in the parent then I would not have needed to touch the individual Child Control's code at all and could have just gone around each parent window implememnting this class

Thanks again.