Re: resize SDI Application Flickers

Delete the above initialization. A CRect has
four values, and NULL is not an allowable
value anyway because NULL is a pointer, not a
permissible data type for a CRect.

The code seems needlessly complex for a simple problem.

See below...
On 23 Aug 2006 03:37:20 -0700, "Neo" <momer114@gmail.com> wrote:


****
Lose callCount. It makes no sense whatsoever
****

****


****
Replace the above code with
    if(c_Llist1.GetSafeHwnd() != NULL)
where c_List1 is a control member variable. The ::IsWindow is not needed, the GetDlgItem
is just plain inappropriate, and why is a call count even involved in this test?
****

****
A CRect cannot be set to NULL. And there is no need to initialize it at all, because the
very next line initializes it.

Get rid of 'this'. There is no need for it. You do NOT want the window rect for this,
you want the client rect
        GetClientRect(&rectWindow)
****

****
Delete the above initialization. A CRect has four values, and NULL is not an allowable
value anyway because NULL is a pointer, not a permissible data type for a CRect.
****


****
You should not be resizing the text control in the conditional for resizing the c_List1.
Getting the window rect is only the first step. You then have to convert it to client
coordinates by doing
        ScreenToClient(&rectItem);
****

****
I have not seen code this bad in a long time. Why do you need to create all these
variables? Why are you using commas in a declaration?
*****

*****
How is it possible that '140' could be a meaningful value? This makes no sense. 140
makes sense only on your machine, with your current display card, the current version of
the displayl driver, your currently set resolution, and your current set of default screen
font height. You cannot write sane code using hardwired window positions
****

****
This is even worse, because there are four hardwired constants here, all of which are
completely meaningless except on your current machine in one configuration. Lose every
single one of these constants, everywhere.

****
What possible value could this have?
****


****
First, write the code correctly. Here's some code that will take an edit control which is
above a CListCtrl and stretch it out to follow the resize of the parent window, and resize
the list control to fill the bottom part of the window. I can't even figure out what your
code is intending to do, so use this as a template and adapt it as necessary

void CProblemView::OnSize(UINT type, int cx, int cy)
    {
     CFormView::OnSize(type, cx, cy);

     if(c_List1.GetSafeHwnd() != NULL)
       { /* resize list */
        CRect w;
        c_List1.GetWindowRect(&w);
        ScreenToClient(&w);
        c_List1.SetWindowPos(NULL,
                                                  0, 0, // ignored
                                                   cx - w.left, cy - w.top,
                                                   SWP_NOMOVE | SWP_NOZORDER);
        } /* resize list */
     if(c_Edit1.GetSafeHwnd() != NULL)
       { /* stretch edit control */
         CRect w;
         c_Edit1.GetWindowRect(&w);
         ScreenToClient(&w);
         c_Edit1.SetWindowPos(NULL,
                                                     0, 0, // ignored
                                                     cx - w.left, w.Height(),
                                                     SW_NOMOVE | SWP_NOZORDER);
      } /* stretch edit control */
   } // CProblemView::OnSize

Note that it takes fewer lines, has no hardwired constants (the 0,0 are ignored), works in
all resolutions with all fonts on all displays, and uses no complex enumeration of
variables that represent copies of values that could have been used directly.

There are variants of this. For example, if you lay the controls out with margins to the
right that you wish to have maintained, you can compute the initial margins in the
OnInitDialog handler and save those so you can subtract them out of the width expression.

No callCount is needed; I can't imagine why you would even think it mattered.

When I have multiple controls to stretch, I usually create a subroutine and pass values
into it, for example

void CProblemView::StretchEdit(CEdit & e)
     {
      if(e.GetSafeHwnd() == NULL)
         return;
      CRect c;
      GetClientRect(&c);
      CRect w;
      e.GetWindowRect(&w);
      ScreenToClient(&w);
      e.SetWindowPos(NULL, 0, 0, c.Width() - w.left, w.Height(), SWP_NOMOVE |
SWP_NOZORDER);
    }

and then in the OnMove handler I'll do
    StretchEdit(c_Name);
                StretchEdit(c_Address);
                StretchEdit(c_Address2);
and so on.

Note that it is considered good practice to IMMEDIATELY replace those silly names like
IDC_EDIT1, IDC_EDIT2, IDC_LIST1, etc. with meaningful names such as IDC_NAME, IDC_ADDRESS,
IDC_LOG, and similar names that have actual meaning, and create member variables that have
actual meaning.

Doing geometry is a simple but tedious problem, and you made it vastly more complex than
it needs to be.

Do eliminate the flicker, you can handle the WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE messages
and 'freeze" all updates to the window until everything is in place. This reduces
flicker, but you also don't see how things are being stretched.
                    joe
*****


Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm