We help IT Professionals succeed at work.

What are the messages related to borders and resizing?

lmarceau asked
Medium Priority
Last Modified: 2013-12-03
Can somegive me a comprehensive list of all Windows' message and API calls related to window borders, window resizing and window moving.
I will also need to know which hook(s) a need to setup to monitor them system wide.
I want to modify the bahavior of Windows when the user is resizing and moving he window around. I need to know enough about those sequences of messages to, let say, give a Unix feel when resizing to Windows.
Maybe you could just point me I can find the info, a URL, the home page of someone who already did such thing, or a shareware/software that would do it for me. I've looked in the Win32 API reference but I could not find a section about borders.
Watch Question

Tommy HuiEngineer

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


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.

This stuff is poorly documented because well behaved programs (written by well behaved programmers) should just use the default behavior.

What you should do, in general, is nothing.  At least that's what Microsoft would prefer.

the real question is what do you need to do?  

I often hook WINDOWPOSCHANGING and use that resize the contents on the window.  For example if a window has a child window that must fill the client area, I resize the child window to fit the new client area.  (This could be done on WM_SIZE, but I don't as there usually are are other things I do on WINDOWPOSCHANGING.

Another type of thing that might be done is to force the window resize to only certain sizes.  DOS box's do this because they must be 25X80 characters.  This is done with the ENTERSIZEMOVE,SIZING,EXITSIZEMOVE messages.

I can (some) more details if you let me know what you want to do.

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts


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;                    

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.  

Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.