none
Taskbar menu cascade and tile (WM_WINDOWPOSCHANGING) RRS feed

  • Question

  • I have an app, which I wrote, and is essentially Win32 written in C++. It does not use MFC but has most of the associated functionality. In fact it's not a bad little app. It works sweetly and quickly, and boy did I try to make it right. It doesn't crash, but there are plenty of instances where I've figured out the way to get windows to work, rather than had the specific knowledge to make it right.

     

    Pretty much the final thing I'm looking at at the moment, relates to the use of the cascade and tile desktop windows, by the use of the menu options on the taskbar menu. IIRC there are two tile options, one cascade option, and a show desktop option. The show desktop option works, but the tile and cascade options don't. From a user perspective they don't appear to drive my app correctly, and I'd like them to work correctly, but I'm not sure what it is that I'm doing wrong.

     

    I've dug into a couple of apps with spy comparing messages with those of explorer, and notepad, and in all cases the cascade option sends WM_WINDOWPOSCHANGING, and WM_WINDOWPOSCHANGED to the top level window. If I do the same with my app window, the XP just doesn't send the cues.

     

    There is some stuff happening before the WM_WINDOWPOSCHANGING that is associated with the cascade operation. Most notable of these is WM_SYNCPAINT. I have tried artificially emulating the behaviour of notepad and explorer in respect of SYNCPAINT, in the hope of something different happening that might yield a clue, and possibly a direction..... To no avail.

     

    I've compared and experimented with my standard and extended window styles, also the class styles. Generally speaking I cant see why XP won't send me the WM_WINDOWPOSCHANG(ING | ED) that I so much need. It must be something to do with the state of the app prior to requesting the desktop cascade or tile, but what is a mystery.

     

    Can anyone shed any light on decision making process that XP undertakes, between hitting the cascade menu option and sending top level windows their instructions.

     

     

    Friday, July 27, 2007 6:06 AM

Answers

  • Job done!

     

    Turns out that a parentless window when created with only WS_VISIBLE is promoted to VISIBLE | CLIPSIBLINGS | OVERLAPPED | CAPTION, by CreateWindowEx (or more probably DefWindowProc). Even if you subsequently use SetWindowLong to force the window down to VISIBLE only, the window is promoted to OVERLAPPED by SetWindowLong.

     

    As it turns out CAPTION allows the taskbar menu to specify move as a result of tile or cascade, and THICKFRAME allows the taskbar to specify size. Thickframe only allows move when caption is also present. Natural and obvious, but then I'm a bit of a slaphead sometimes!

     

    Actually that was the exact problem (a lack of WS_CAPTION on the app window), that was because it was an easy way to avoid cropped window corners, a la XP.

     

    The solution to that problem was to use SetWindowRgn in WM_NCPAINT, using a rectangular region with zero origin co-ordinates and a size the same as that of the rectangle passed to WM_NCCALCSIZE.

     

    Hope that helps someone!

    Smile

    Friday, July 27, 2007 10:00 PM

All replies

  • Well, I made a bit of progress........

     

    Turns out that the functionality I'm hoping for is specifically associated with WS_OVERLAPPEDWINDOW. specify the style, and you get the functionality, don't and you wont.

     

    Trouble is that, I'm trying to avoid using that style, because I like square corners on my windows! As usual, to get what you want you have to solve a different problem.

    Friday, July 27, 2007 6:23 PM
  • Job done!

     

    Turns out that a parentless window when created with only WS_VISIBLE is promoted to VISIBLE | CLIPSIBLINGS | OVERLAPPED | CAPTION, by CreateWindowEx (or more probably DefWindowProc). Even if you subsequently use SetWindowLong to force the window down to VISIBLE only, the window is promoted to OVERLAPPED by SetWindowLong.

     

    As it turns out CAPTION allows the taskbar menu to specify move as a result of tile or cascade, and THICKFRAME allows the taskbar to specify size. Thickframe only allows move when caption is also present. Natural and obvious, but then I'm a bit of a slaphead sometimes!

     

    Actually that was the exact problem (a lack of WS_CAPTION on the app window), that was because it was an easy way to avoid cropped window corners, a la XP.

     

    The solution to that problem was to use SetWindowRgn in WM_NCPAINT, using a rectangular region with zero origin co-ordinates and a size the same as that of the rectangle passed to WM_NCCALCSIZE.

     

    Hope that helps someone!

    Smile

    Friday, July 27, 2007 10:00 PM