Parent Dialog's labels are vanishing for little bit of time when the child dialog exit
-
Hai all, One of my dialog based application, I call a child dialog from parent dialog , Parent dialog's labels (Underneath of child dialog) will vanish for a while , while i exit the child dialog. how to avoid this problem ? Thanks in advance.
-
Hai all, One of my dialog based application, I call a child dialog from parent dialog , Parent dialog's labels (Underneath of child dialog) will vanish for a while , while i exit the child dialog. how to avoid this problem ? Thanks in advance.
Can you more explain when you call child then label of parent is hide?
-
Hai all, One of my dialog based application, I call a child dialog from parent dialog , Parent dialog's labels (Underneath of child dialog) will vanish for a while , while i exit the child dialog. how to avoid this problem ? Thanks in advance.
When then child dialog disappears, the underneath area needs to be repainted, so the parent dialog (and some controls) are invalidated, ready for a WM_PAINT message. My guess is that you have something like:
void CParentDlg::OnSomeButton ()
{
CCHildDlg dlg (this);dlg.m_ManyThings = Blah;
if (dlg.DoModal () != IDOK) return;
DoSomeVerySlowStuff ();
// ChildDlg's destructor implicitly called here.
}The paint messages won't be handled until after
CParentDlg::OnSomeButtonreturns. So, are you doing some slow steps? If you cancel out of the child dialog, is the repainting faster? Is the child dialog doing loads of things in its destructor? Or in its OnDestroy method? Iain.Iain Clarke appears because CPallini still cares.
-
When then child dialog disappears, the underneath area needs to be repainted, so the parent dialog (and some controls) are invalidated, ready for a WM_PAINT message. My guess is that you have something like:
void CParentDlg::OnSomeButton ()
{
CCHildDlg dlg (this);dlg.m_ManyThings = Blah;
if (dlg.DoModal () != IDOK) return;
DoSomeVerySlowStuff ();
// ChildDlg's destructor implicitly called here.
}The paint messages won't be handled until after
CParentDlg::OnSomeButtonreturns. So, are you doing some slow steps? If you cancel out of the child dialog, is the repainting faster? Is the child dialog doing loads of things in its destructor? Or in its OnDestroy method? Iain.Iain Clarke appears because CPallini still cares.
Thanks your reply. What you mentioned is exactly correct. How Can i Avoid such trouble please clarify. Thanks Vicky
-
Thanks your reply. What you mentioned is exactly correct. How Can i Avoid such trouble please clarify. Thanks Vicky
vicky00000 wrote:
How Can i Avoid such trouble please clarify.
By not doing complex work on returning from the dialog. There are a few choices I can think of (and millions others, I'm sure) - how useful each is depends on how long the pause is - a slightly irritating half second, or many seconds. I'm assuming it's not hoooooours. 1/ Do the work in the child dialogs OnOK window, and use CWaitCursor just before you do it. The child dialog will stick around, but it won't be a mystery. 2/ After the DoModal () returns, post a message to yourself, and do the long work in that message handler. this postpones the work until after the painting is done. 3/ After the DoModal () returns, start up a worker thread, and have that post a "I'm done" message. Iain.
Iain Clarke appears because CPallini still cares.
-
Thanks your reply. What you mentioned is exactly correct. How Can i Avoid such trouble please clarify. Thanks Vicky
vicky00000 wrote:
What you mentioned is exactly correct.
So are you calling the second dialog's destructor explicitly (in some button handler)?
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
-
vicky00000 wrote:
What you mentioned is exactly correct.
So are you calling the second dialog's destructor explicitly (in some button handler)?
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
DavidCrow wrote:
are you calling the second dialog's destructor explicitly
I am not sure why calling destructor explicitly? It should never be done. In this case, dialog object is allocated on the frame and it dies when function goes out of scope; destructor is called automatically. vicky00000: Well, I fail to see child-parent relationship between dialogs. Both most likely are owned by main window (it could be the first dialog). As for doing long processing, follow Iain’s advice #3. Do the background processing in a worker thread. As for CWaitCursor, it is a legacy class from 16-bit Windows. In 32-bit it will disappear as soon as ne WM_SETCURSOR message is received. If you want to show hourglass, it is better to handle WM_SETCURSOR message and call SetCursor to change cursor for a dureation you need.
JohnCz MS C++ MVP