locked
WM_SIZE and Vista RRS feed

  • Question

  • I have trouble that under Vista x64 some WM_SIZE messages dissapear, under all other Windows it works fine.

    In my application I have very complex splitter structure. The bug appear when I change size of main window. In this case WM_SIZE message is got by the first and the second layer of splitter and is not got by third layer. However when I change position of splitter of first layer - WM_SIZE is got.

    Every layer is implemented by the same MFC class.

    I found that default handler (DefWindowProc) of WM_WINDOWPOSCHANGED is processed in different ways (i.e. the same data putted into this function cause different behaviour). This is the reason.

    How to solve this issue?

     

    P.S.

    Similar issues I have with Visual Studio. From time to time some of frames are not drawn at all until I change splitter position.

    Monday, October 1, 2007 8:12 AM

All replies

  • I've developed softwares for different versions of windows, many of the things you talking about happened in these windows. It seems not bugs of the windows in most of cases because i've found many windows or controls using SetWindowPos API with flages that cause no WM_SIZE messages being sent. You can handles WM_WINDOWPOSCHANGED (and without WM_SIZE being handled again) to solve it.

     

    Sunday, October 7, 2007 7:21 PM
  • You know I replace SetWindowPos with MoveWindow and nothing changed. Also th strage thing that first to layers of my splitter got all messages but the last not. And under XP (and previous windows) I have no such problems.

     

     When microsoft open code (at least for view) of such dll's as user32.dll

    Monday, October 8, 2007 5:56 AM
  • Changes nothing if you just changes SetWindowPos/MoveWindow or whatever those API. The fact is you aren't able to changes these APIs that other module's designer or frame's designer decided to use.

    Repeat again:

    Proceed WM_WINDOWPOSCHANGED message instead.

    Additional:

    You'd better let your APP(your code) proceed WM_SIZE of popup/main windows and WM_WINDOWPOSCHANGED message of child windows.

    Otherwise some window in your app may behaves strangly like overlays incorrectly, unpaint some area when large a window, most likes what you have said.

    The splitter must send some notification messages after you have drag it. Try to proceed one of them that caused by WM_WINDOWPOSCHANGED, not others that caused by WM_MOVE/user behaviours directly.

    Anything like this will happen:

    started->You drag a splitter with mouse/keyboard->the splitter collect information[1] and packed as notification message(s) and send to its parent->the splitter changes the size and position of itself->the splitter collect information[2] and packed as notification message(s) and send to its parent->done.

    You see, if you proceed the notification messages that means 'can be placed no matter section just for sending', the incompatible may happen when Win OS has been updated. so you have to find a message that is meanful only in section [2].
    Wednesday, October 10, 2007 10:11 AM
  •  

    I faced up with this problem more than a year ago, when I tried my app under original XP (e.g. no service packs or updates), it was huge window with many many child windows on it. I tried under XP 32bit and it behaved exactly like you described. 

     

    A little investigation showed that Windows stops sending WM_SIZE when it reaches some certain nesting level. In other words, it won't send WM_SIZE to your child windows if you try to resize them when you process WM_SIZE in the parent ones. Depending on the USER stuff/updates/serivice packs the maximum nesting level at which it stops propagating WM_SIZE may vary from 15 to 31 and even much higher (effectively unreachable) under latest XP 32bit/sp2.

    But it still too little under XP x64 and still some similar ugly things happen to other messages under some builds of Vista.

    So it is certainly a Windows bug.

     

    To solve the problem I'd recommend to avoid synchronous rese for the child windows and  use PostMessage to inform them that they should resize a bit later when postes message reaches them. It will eliminate deep recursion and you will get your app resized correctly.

     

    -jv

    • Proposed as answer by CharithJ Monday, July 11, 2011 11:32 PM
    Sunday, October 21, 2007 4:30 PM
  • Hi,

    I know this is an old topic, but I'm facing this issue and I don't know how to deal with it. I hope you could help.

    I understand the problem of kernel stack overflow, and I tried different possible solutions but every time it causes others problems. I can't use another thread to resize the children components because of data access...

    JVlad, you're talking about using PostMessage to tell the children to resize a bit latter. I would like to try that but I have no idea how to do it, can you help me ?

    Thanks

    Thursday, August 12, 2010 6:22 PM