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?...
Main Topics
Browse All TopicsHello everyone...
I read somewhere in the MSDN using a GroupBox it could be a container for controls so I tried to create one and to put inside some controls like Edit Control, Radio Button...then implementing the OnSize on PropertyPage I coded:
CWnd* pWnd = GetDlgItem(IDD_CFG_CFGBASI
if ( pWnd )
{
CRect rect, rectDlg;
pWnd->GetWindowRect( &rect );
ScreenToClient( &rect );
int nWidth = rect.Width();
int nHeight = rect.Height();
GetClientRect( &rectDlg );
rect.left = (rectDlg.Width() / 2) - (nWidth / 2);
rect.top = (rectDlg.Height() / 2) - (nHeight / 2);
rect.right = rect.left + nWidth;
rect.bottom = rect.top + nHeight;
pWnd->MoveWindow( &rect );
}
it moved the group box in the middle of the PropertyPage when resizing but the controls inside didn't moved with the group box.
So I'm thinking to create something like a frame resource with those controls so I could put the frame in the middle of the propertypage with the controls inside... I found an example here:
CMyFrame is a CFrameWnd created with class wizard
CMyView is a CFormView created with the class wizard
I want CMyFrame to always incorporate CMyView as the view. Make sure MyFrame.cpp includes MyView.h
bool CMyFrame::LoadFrame(..., CCreateContext* pContext)
{
CCreateContext ctxt;
if (pContext == 0)
{
ctxt.m_pNewViewClass = RUNTIME_CLASS(CMyView);
pContext = &ctxt;
}
if (CFrameWnd::LoadFrame... (the rest is created by the wizard)
}
tried this approach but I guess I'm lost in the middle of nowhere... do you have a suggest to create this "container"?...
Thanks to all!
Ciao,
Luigi
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
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)
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.
? 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.
>>>> is there something like a refresh function which would repaint the DC avoiding me to hide and re-show?
You also could call LockWindowUpdate before all moving and and UnlockWindowUpdate to repaint after all is done.
>>>> so the only way is to move each control with that OnSize
Doing updates in OnSize is less recommendable cause the OnSize was called after the window already was resized. Better use the OnSizing (handler for WM_SIZING) which was called prior to the window update (So, that you can correct or even prevent sizing). With that handler, you could do all moves without flickering.
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! :-)
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
CButton* page2Check = (CButton*)page2->GetDlgItem
if (page2Check->GetCheck() == BST_CHECKED)
CClass_Page2::ActivatePage
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
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/UnlockWin
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()....Unlo
>>>> More important - just wrapping the existing code in the OnSize inside LockWindowUpdate()....Unlo
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(U
{
LockWindowUpdate();
CFormView::OnSize(nType, cx, cy);
if(GetDlgItem(IDC_BUTTON1)
{
DoMove(IDC_BUTTON1);
DoMove(IDC_BUTTON6);
DoMove(IDC_BUTTON11);
DoMove(IDC_BUTTON16);
}
UnlockWindowUpdate();
}
void
{
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...Unlock
>>>> 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/UnlockWin
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.
Well, as certain windows don't receive WM_SIZING I will leave it to anyone looking at this Q. to decide what message to respond to.
Resizing - the app I attached uses a LockWindowUpdate..move/res
ps. I do understand what is causing the flickering and moving/resizing the controls is only part of it.
Business Accounts
Answer for Membership
by: AndyAinscowPosted on 2009-09-22 at 01:45:17ID: 25390696
You have misunderstood.
The group box can 'contain' controls such as radio buttons BUT it has nothing to do with resizing them. It is how the tab and space keys move from one control to the other inside the group box.
To move/resize you need to handle EACH control. That is how MFC implements it.
ps. It looks like the frame you supply example code for is a frame window. (Still not what you want, even if you did get it working.) Your app (SDI or MDI) would consist of a frame window which has the title bar, menu, toolbar, status bar...