Re: resize SDI Application Flickers

From:

"Tom Serface" <tserface@msn.com>

Newsgroups:

microsoft.public.vc.mfc

Date:

Fri, 25 Aug 2006 08:18:04 -0700

Message-ID:

<uTv6qmFyGHA.2168@TK2MSFTNGP06.phx.gbl>

Take a look at this guy's code:

http://www.codeproject.com/dialog/resizabledialog.asp

And

http://www.codeguru.com/cpp/w-d/dislog/resizabledialogs/article.php/c1917/

Also, the XTreme Toolkit we use (a purchased libary) has very good flicker
free dialog support: http://www.codejock.com. It's pricey, but it includes
a lot of things that could take you a lot of time to write yourself.

Tom

"Neo" <momer114@gmail.com> wrote in message
news:1156513075.477838.39420@p79g2000cwp.googlegroups.com...

Thanks.

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.

I am not understand how to use WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE
message for eliminate flickering problem, please refer some material
for resolve flickering problem using these messages.

Regards,
-aims

Joseph M. Newcomer wrote:

It is a question of semantics. NULL means a pointer. In fact, in C,
NULL is defined as
(void *)0, but in Windows, that wouldn't work because a handle, which is
not a pointer,
can have a NULL value. But logically it makes no sense to assign a
pointer-meaning name
to a rectangle, so you should write
CRect r(0,0,0,0);
or
CRect r = {0,0,0,0};

to make it clear that you are assigning integer values. By programming
convention, you
don't use things that look like pointers to represent integers, you don't
use integers to
represent pointers, you don't use non-boolean values to represent boolean
computations,
etc.

It is an issue of clarity of style. What the macro is *defined as* is an
implementation
detail. What it *represents* is a null pointer or null handle. Do not
use it in any
context in which a null value has no meaning. There is no concept of
initializing a
rectangle to a null value, because null is meaningless; a rectangle is a
4-tuple of
integer values and should only be acted upon by things that are integer
values.
joe
On 24 Aug 2006 05:06:49 -0700, "Neo" <momer114@gmail.com> wrote:

I am thankful to you for correction in my resizing code. One thing I
don't understand is that you said:

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 said "NULL is a Pointer". NULL is defined as Zero and my
understanding is that a pointer that points to NULL is called a
NULL-Pointer.

I would like to understand that how NULL is a pointer itself.?

Regards,
-aims

Joseph M. Newcomer wrote:

The code seems needlessly complex for a simple problem.

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

I made SDI Application in vs2k5. My View class called CproblemView is
inherited from CFormView class. I placed one CListCtrl and one
Multi-line CEdit Control on it for performing resizing on these
items.
I wrote the following code in WM_SIZE message. (callCount is
initialized to Zero (0) in constructor).

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

void CproblemView::OnSize(UINT nType, int cx, int cy)
{
this->SetScrollSizes( MM_TEXT, CSize( cx, cy ) );
CFormView::OnSize(nType, cx, cy);

****

//IDC_LIST1 is Resource ID of List Control
if( ::IsWindow( this->m_hWnd ) && this->GetDlgItem( IDC_LIST1 ) !=
NULL && callCount == 3 )

****
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?
****

{
CRect rectWindow = NULL;

****
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)
****

this->GetWindowRect( rectWindow );

CRect rectItem = NULL;

****
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.
****

//m_TextControl is Object of CListCtrl
this->m_TextControl.GetWindowRect( rectItem );

****
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);
****

LONG t1 = rectWindow.top,
l1 = rectWindow.left,
r1 = rectWindow.right,
b1 = rectWindow.bottom,
t2 = rectItem.top,
l2 = rectItem.left,
r2 = rectItem.right,
b2 = rectItem.bottom;

****
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?
*****

//m_TextControl is Object of CListCtrl
this->m_TextControl.MoveWindow( 0, 140, r2 - l2, cy - (t2 - t1) );

*****
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
****

//m_List is Object of CEdit
this->m_List.MoveWindow( 265, 15, cx - 265, cy - 15 );

****
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.

}
else
callCount ++;

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

}

Now when I resize SDI Application Flickers A LOT on Resizing time
using
mouse. Does my code has any problem that is causing the flickering?

****
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
*****

Regards,
-aims

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