What are the messages related to borders and resizing?

Take a look at the windows messages sent to a window with Spy++. That will give you a good understanding of the messages.

Yes, spy++ will be an absolute necessity in your task (I've had to do the same sort of stuff), but a couple of messages to get you started:

If you need to be notified when a window size/position/Z-order changes (regardless of the cause, could be from a API function, could be user action) you can use

WM_WINDOWPOSCHANGING or WM_WINDOWPOSCHANGED

The changING version allows you to examine the new position etc and adjust it before the window is actually moved.  The changED version notifies you after the window was moved.  If you are just interested in the new size and don't care about the position (often the case) you can look at WM_SIZE.  This message is sent by the WINDOWPOSCHANGED so it is after the window has been resized.

If you are interested in monitoring/controlling the resizing/moving as performed by the user (mouse) you'll want to look at WM_ENTERSIZEMOVE,WM_MOVING,WM_SIZING, and WM_EXITSIZEMOVE.

If you provide more particulars about what you need to do, I might be able to give more help.  Otherwise you'll need Spy++ (you probably will anyways).

Thui: This is not what I meant by comprehensive!!
Sure I've already use Spy++ to look at what going on. I need the kind of information that Spy can't provide: What are the message that goes together and the meaning of the message that is not expressed in the name.
Niotod's is more helpfull: The reference ralely state what differences there are between similar messages.
Now, could tell me how application are suppose to respond to those message? Or more precisesly: what DefWindowProc does with those messages?

Btw, do you know a good book that give the kind of comprehension of the windows API? Maybe a class textbook for a Windows programming university course would be a good help.

Yes, I know about how important it is to stick to default behavior. I will often do the same kind of remark myself.
But now the purpose of the exercise _is_ to change the default behavior, not to have my app behave in a not-so-cool-nonstandart-way.
I love the way Unix resizes its windows, it would be cool to have it on Windows too. They are some other ideas about new resizing behavior I would like to try. Like to be able to 'stick' a window to another and have them moved together. That would mean I could have a floating control panel to select the desired bahavior and some button for tools like 'stick'.

This is also why I need to know how to have a system wide hook on all those messages. Can you tell me how you do you WINDOWSPOSCHANGING?

I never said that it was important to stick the the default behavior!  I said that Microsoft wanted us to.  I've spent the last week writting my own MDI interface because I don't like Microsofts...

I'll get back to you on WINDOWPOSCHANGING latter.  (Maybe tonight, probably tommorow)  However, it is pretty well documented.  You get the new coordinates, dimensions, etc in a structure (You don't want to use API calls to get the window's dimensions or coordinates, you'll get the old values) and you get some flags that indicate which values are changing.  You can adjust any of these you wish and leave the others alone.  You can even make it change things that it wasn't originaly going to change.  
Oh I forgot an important point.  After you play with these values you passthem to the default window procedure to have the changes actually performed.  

Oh, I gotta go.  Dinner time.

Remember, I want to change the default behavior. Not the behavior of the window that I own.
I will need to hook the mmessage system wide and to pass them to the window in my hook procedure after I have modify the messages.

Oh.  I did not understand that.  Suddenly I don't want to help you anymore.  The Microsoft police already have me under suspicion. . .

Yes, looking back that is what you said.    Boy, I wasn't paying attention.  That's going to be fun.  Actually it shouldn't be all that hard (but it probably be.)

I'm not sure what these "stuck" windows look like.  My only experience with a windows UI in UNIX was SunTools about 8 years ago and that UI was not worth modeling.  But I'll assume that the windows look normal and it is just that when you move one, the others keep the same relative position. You could hook all the messages and look for either WM_WINDOWPOSCHANGING, WM_WINDOWPOSCHANGED, or WM_MOVED.  MOVED might be the best in this case, since it won't occur for resizing or Z-order changes.  Also the window will already be in the new position.  Then you can use MoveWindow() to move the other "stuck" windows.  (You might want to use DeferWindowPos() if there will be more than one or two windows to move.  Faster and lots less screen flashing.)  Note that moving the other windows will generate a flurry of movement messages.  You'll either want to turn of your processing at this point (probably not the best idea in a multi-threaded world) or you'll want to make sure that you don't move a window that is already in position.  

Are there other changes you need to make to the UI?
Oh, I almost forgot about WINDOWPOSCHANGING.  This is documented okay.  But to summarize, the LPARAM points to a WINDOWPOS structure

typedef struct _WINDOWPOS {
    HWND hwnd;                    
    HWND hwndInsertAfter;          
    int  x;                        
    int  y;                        
    int  cx;                      
    int  cy;                      
    UINT flags;                    
} WINDOWPOS;

the flags are documented and are the same flags that can be passed to SetWindowPos().  (No cooincidence I assume.)  The flags indicate what things are changing, lke if the window is being moved, resized, or changed in the Z-order.  The rest of the structure indicates how it is changing.  Some of the flags are backwards, though.  i.e. if the SWP_NOMOVE is specified, the window is not being moved.  In that case the x and y members will be ignored and are probably garbage.  It the flag is cleared, the x and y members are the new position and if you change then it will be moved to the position you specify.  I suspect you get the idea.  If you have any questions...

Looking back there is something I implied but didn't make clear.  if you hook the WINDOWPOSCHANGING you'll be looking at things before windows are moved.  This may cause infinite recursion if you are note careful.  For example. say windows A and B are hooked together.  If the user moves A you find out that a is ABOUT to move.  You check to see if B is in the right position and find it is not, so you try to move B.  You find out that B is ABOUT to move and check to see if A is in the right position.  Unfortunately A hasn't actually moved yet so you find out it is in the wrong position and try to move it to the same position that the 1st message was going to . . .

If you hook WM_WINDOWPOSCHANGED (same as changing, but occurs after the change) you can find out if a window is already in the desired position and not move it.

There are other ways around this problem, but this might be the easiest.

Thank you Nietod! I think I almost can get started. I need one last thing though:
Which type of hook do you install to get WM_WINDOWPOSCHAGExxx, WM_SIZING and all the others related message? I can't figure it out from the referrence of SetWindowsHookEx().

I've never tried it before...
A little research indicates things might be a little complex.
The WH_GETMESSAGE hook is best since you can modify the messages it hooks before the messages are processed.  However, it only gets messages that go to the message queue.  The messages you want (probably) don't  (Isn't windows just perfect!).  

That means you have to use WH_CALLWNDPROC.  For some reason, you can't modify these messages however.  That's probably a good idea in terms of security and system reliability.  But allowing you to  modify the ones that go though the queue certainly circumvents that.  This means thay you (probably) can't take actions by modifying these messages, but you can still get notified when a window is moved, decode the window message parameters to find out  what window and where it was moved to and then move other windows via MoveWindow(), SetWindowPos(), or DeferWindowPos().

You'll probably just have to experiment.  You can ask for more advice, but I'm probably getting to the edge (way past it really) of my knowledge.  There are other experts who can probably provide more info than I, if you need it.  Despite his rejected answer, Thui is probably one of your best bets for more info.  There doesn't seem to be anything he doesn't know.

You made me looked futher in the references. I had never remarked that some hooks could modify the messages and some couldn't.
But doing some I think I've felt rigth on the one a need. Take a look to the WH_CBT computer-based-training hook. It is not designed for jungling with the border. It does not directly catch the message. But it gets informed about windows that are changed or sized and it is allow to modify the message. Exactly want I need!! Yahoo! I can start coding now.

Thank you pal.


( Messages that don't go to the queue?? Where can they go then? Can you give me a clue what they are about? see ya)

Messages "sent" with PostMessage() go into the queue and are removed by the message loop (GetMessage()).

Messages "sent" with SendMessage() go directly to the window procedure.  That, is the window procedure is called by the SendMessage() procedure.  

The vast majority of messages are sent, not posted, so the message loop tends to do very little.