MFC Frame resource

Hello AndyAinscow,

I'm implementing a MFC Dialog application based on CPropertyPages and CPropertySheet...so the only way is to move each control with that OnSize where I move the groupbox, right?...

Yes.  (You might find some third party tool or code but that would just be wrapping a lot of MoveWindow calls).

OK I just implemented something: when I move the first control (the groupbox) I calculate the difference of movement space and I pass it to a function with three parameters, control CWnd, top difference and left difference and it works.... just only a thing: when I resize the form dragging the border it looks like "dirty" so I have to hide the form in the background then re-show.... is there something like a refresh function which would repaint the DC avoiding me to hide and re-show? (indeed when I maximize or restore it works perfectly)

Try to call Invalidate();

When you maximize then you get one message to respond to.  When you drag to reisze you get multiple messages for the resizing (how many depends on various factors eg. PC workload, mouse).  You are likely moving/sizing in response to each.
You need to somehow reduce the umber of sizing messages you respond to.

Oh looks like that Invalidate() works! :-)

?  That should not be necessary, the resizing should call Invalidate in the background.

If a call to Invalidate works then are you implementing an OnPaint (or OnDraw) handler ?  
OR are you not calling the base class OnSize handler in your OnSize routine?  If that is the case then you might be making other problems for yourself.

Yes in fact I have implemented OnPaint in the CDialog form application due to show the icon when minimize window....

That shouldn't interfere if it is only for the minimize.
You are calling the base class OnSize function in your OnSize handler ?

Indeed.... OnSizing doesn't work and I have to leave the code in OnSize (the WM_SIZE base event in CPropertyPage) but at least I changed Invalidate() with LockWindowUpdate() and UnlockWindowUpdate() since reminds me right from past BuilderC++ implementations "DisableControls();" "EnableControls();" which prevents flickering.

Ah BTW, I found a way to have such a "container"...and it's a dialog! To be precise I can have a child dialog on a dialog BUT it has disadvantages: I should have separate procedure for child dialog and therefore some communitcation between parent dialog and child dialog so it isn't really useful.. :-)
Thanks to all though! :-)

That would only be useful to move controls, not for a resizing of the controls on the form.

In fact so I did...ok about moving components..and how I can execute methods of other PropertyPages when I need to do an action like disable some controls?...
Because I tried this:

(CPropertyPage*) page2 = (CPropertyPage*)GetDlgItem(IDD_CONFIG_PAGE2);
CButton* page2Check = (CButton*)page2->GetDlgItem(IDC_CHECK_PAGE2);
if (page2Check->GetCheck() == BST_CHECKED)
   CClass_Page2::ActivatePage2Controls(FALSE);

and I get and "Illegal call of non-static member function", but in this case I want to execute a method that has to disable controls in that page...

Thanks
Luigi

That is getting rather away from the original question.

ON_SIZING doesn't produce result of moving controls which does ON_SIZE indeed.

What has that comment you have accepted as an answer to do with the question you originally asked?

Because I started asking about a "container" which I could contain controls then moving the container around the parent but got there aren't containers but moving controls then I figured I could have a child dialog window belonging main window, even with disadvantage to have some communication between dialogs, so I thought it was like I found myself a partial solution but after adopting controls moving there was the problem of flickering and as solution I adopted the LockWindowUpdate/UnlockWindowUpdate to prevent flickering and solve and close the problem to continue with another question...if isn't enough I can split points also for adopting moving controls...

Considering you didn't understand the 'container' I think you see why I was surprised that improving your knowledge there was little valued by you.

Also note (as you stated later) the WM_SIZING suggested there didn't work.

More important - just wrapping the existing code in the OnSize inside LockWindowUpdate()....UnlockWindowUpdate() does not stop (or obviously reduce) flickering as you resize.

>>>> More important - just wrapping the existing code in the OnSize inside LockWindowUpdate()....UnlockWindowUpdate() does not stop (or obviously reduce) flickering as you resize.

That is not true. I did it recently for a similar task where a bunch of controls newly were created, resized and moved. The LockWindowUpdate trustfully suppresses any automatic refreshes and paintings.

Also the WM_SIZING works when the right window was chosen.

>>Also the WM_SIZING works when the right window was chosen.

Does that mean that WM_SIZE is the usual message to handle for move/resize of child controls ?



I have also done a simple app.  Attached is the compiled, release version - note you must change the extension from txt to exe.  (EE wouldn't accept the source code even when packed into a zip)

This is the relevant code section:
void CzTestResizeView::OnSize(UINT nType, int cx, int cy)
{
   LockWindowUpdate();

   CFormView::OnSize(nType, cx, cy);

   if(GetDlgItem(IDC_BUTTON1) != NULL)
   {
       DoMove(IDC_BUTTON1);
       DoMove(IDC_BUTTON6);
       DoMove(IDC_BUTTON11);
       DoMove(IDC_BUTTON16);
   }

   UnlockWindowUpdate();
}

void CzTestResizeView::DoMove(UINT nID)
{
   CRect rc;

   for(UINT i = 0; i < 5; i++)
   {
       GetDlgItem(nID + i)->GetWindowRect(&rc);
       ScreenToClient(&rc);
       GetDlgItem(nID + i)->MoveWindow(rc.left+1, rc.top, 50, 20);
   }
}



Try resizing the app - it flickers (note the code inside the OnSize is just wrapped inside the LockWindowsUpdate...UnlockWindowsUpdate block  which 'The LockWindowUpdate trustfully suppresses any automatic refreshes and paintings.' ).

>>>> Does that mean that WM_SIZE is the usual message to handle for move/resize of child controls ?

No, quite the contrary. The WM_SIZE was sent to inform the window that its size had changed. That means any paintings involved with the resizing or moving already had happened and doing any corrections or even calling other OnSize handler most probably will cause a flicker.

The LockWindowUpdate/UnlockWindowUpdate is a low level mechanism what means it shouldn't be used to prevent from paintings in another high-level handler function like OnSize but should be used to protect from early paintings when a series of windows (controls) were created, moved or resized as it for example is the case when you need to resize/move a whole dialog with all controls, frames, icons, images and so on. By locking the window any WM_PAINT message caused by invalidation or initialization of windows will be suppressed. But of course it has no effects on paintings already happened!

That's why I suggested to handle WM_SIZING rather than WM_SIZE cause it was issued prior to any paintings. But WM_SIZING wasn't sent to any window but only to those which actively provide resizing capabality, e. g. frame windows.