Win32 API Maiximize/Restore Down problem

This is a discussion on Win32 API Maiximize/Restore Down problem within the Windows Programming forums, part of the Platform Specific Boards category; I have a program that uses 5 child windows. I answer the call for WM_PAINT in the childproc callback function. ...

  1. #1
    {Jaxom,Imriel,Liam}'s Dad Kennedy's Avatar
    Join Date
    Aug 2006
    Location
    Alabama
    Posts
    1,065

    Win32 API Maiximize/Restore Down problem

    I have a program that uses 5 child windows. I answer the call for WM_PAINT in the childproc callback function. I answer the call for WM_SIZING in the parentproc callback function. The windows paint fine for dragging the window, however, upon the MAXIMIZEBOX clicked, the windows fail to paint properly. Three of the five boxes have scroll bars, of which two are verticle. The vertical bars show up incorrectly (the slide bar is smaller than it should be) and there is not enough data in the window. These two windows are not standard ListBoxes, however, they have been written similar to the way a list box would work. Due to shading requirements of the data, I couldn't use the standard listbox window type.

    When the user clicks "Restore Down" after a Maximize, the bottom right window is completely left out. I have to drag the window down about 20 or 30 pixels in order for the window to repaint properly.

    What appears to me to be happening is that my PAINT code (in which I also recalculate and move the child windows each time -- probably shouldn't do that, but hopefully that isn't what is causing the problem) is getting interim coordinates from the system before the parent window actaully paints, then I paint out of the window and thus my bottom right window is no longer in the UpdateRegion, therefore it never gets the message WM_PAINT until I reach the location where some part of it is in the UpdateRegion area.

    Anybody got any ideas as to what I'm doing wrong?

    Andy
    Last edited by Kennedy; 08-08-2006 at 11:47 PM.

  2. #2
    {Jaxom,Imriel,Liam}'s Dad Kennedy's Avatar
    Join Date
    Aug 2006
    Location
    Alabama
    Posts
    1,065
    In an attempt to make sure that I had the window in the right location at all times, any time that a WM_PAINT was called I moved the window. Whereas, based on the way I have written my code, I would never have overwritten a child window with another child window (as All My Children were actaully calculated on the fly, every time) I did have an issue with WM_PAINT being called when the Maximize/Restore Down (MRD) button was pressed. What I figured out was happening was that the MRD was sending a message to the parent WM_WINDOWPOSCHANGED. Then, the defwindowproc would send the WM_MOVE and WM_SIZE to the parent window, which in turn would send the WM_PAINT to the child windows EACH TIME, which makes sense. The real issue came into effect when, apparently (based upon countless repetitions) these two commands are processed "at the same time" which is a misnomer, as these two processes actaully usually are called WM_MOVE then WM_SIZE, however, not always (2 times out of about 50 was opposite). During the call to WM_MOVE the parent window posted a message to all of the children to WM_PAINT. During the call to WM_SIZE all the children get another message to WM_PAINT, this time in reverse order (I have know idea why). In the second call to WM_PAINT, the parent window IS NOT RESIZED YET, however, the client area is invalidated. This caused my last child to paint out of the client area. The solution was to (1) remove the Move from within the WM_PAINT message, (2) do NOT answer the call to WM_MOVE nor WM_SIZE within the child proc and (3) answer the call to WM_SIZE under the parent proc. The only way I could figure to handle this event is to allow the defwindowproc to do whatever it would normally do, then run a loop telling all my child windows to WM_NCPAINT, WM_PAINT, then InvalidateRect(<child wnd handle>, NULL, TRUE). If I left off the WM_NCPAINT, the border didn't show up right -- EVER. Leaving off WM_PAINT caused the child area to paint properly about 80% of the time. Without calling InvalidateRect on the child window, either of these wouldn't paint EXACTLY correct each time.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Textbox in Win32 API ???
    By actionbasti in forum Windows Programming
    Replies: 1
    Last Post: 11-07-2003, 02:29 AM
  2. Win32 API Questions
    By CPP-Null in forum C++ Programming
    Replies: 1
    Last Post: 05-25-2003, 05:26 PM
  3. Win32 API
    By Liger86 in forum Windows Programming
    Replies: 2
    Last Post: 01-30-2003, 02:19 PM
  4. progress bars with Win32 API
    By bennyandthejets in forum C++ Programming
    Replies: 15
    Last Post: 09-10-2002, 05:25 AM
  5. Is it foolish to program with Win32 API ?
    By Kelvin in forum Windows Programming
    Replies: 2
    Last Post: 07-09-2002, 03:03 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21