Modeless Dialog Boxes - Knowing when it terminates, Terminate without using delete Dlg and Getting input Focus

Modeless Dialog Boxes - Knowing when it terminates, Terminate without using delete Dlg and Getting input Focus

Post by Compute » Thu, 24 Nov 2005 09:26:37


Hi,

I am using a Modeless dialog box.

1. When I launch the Dialog box, how does one know when it ends?
Does it have to post a message back to the calling CWnd?
Is that the standard method?

2. I am using Animate to close the Dialog.
Instead of using delete dlg; I call a method CloseTheDialog(), then dlg
= NULL;
After the Timer has expired for my nifty closing animation, I post a
WM_CLOSE message to itself.
I can see it going though the motions of closing, except for the
destructor CDlg::~CDlg.
When the App quits, I get memory leaks because the Dlg object is still
hanging around.
If I don't set dlg=NULL, and in my desctructor CView::~CView, I delete
the dialog object
if(Dlg != NULL){ delete Dlg; }
I see it calling the destructor CDlg::~CDlg and I get no memory leaks.
Am I to understand that closing a Dialog Box, doesn't necessarily delete
the Dialog Object?
I've tried adding delete this; to no avail.
I could post a message back to the calling CWnd, but I am curious as to
why the object is not getting deleted.

3. It's strange, but the mouse seems to be going to the background View,
instead of the focus being on the Modeless Dialog.
Shouldn't the Modeless Dialog automatically regain input focus?
Do I have to add some Mouse Even for the Modeless Dialog Box to regain
input focus?


Thanks again,
--
 
 
 

Modeless Dialog Boxes - Knowing when it terminates, Terminate without using delete Dlg and Getting input Focus

Post by Tom Serfac » Thu, 24 Nov 2005 09:34:19


That's what I do. It's easy enough to do in the OnClose() or destructor
routines using GetParent()


You are correct. The dialog object is an object you can either have on the
stack or create with a new. The "dialog" is a window that gets created.
You should always delete dynamically created objects unless you know someone
else does it for you (like bitmaps loaded into CBitmaps for example).


Don't know about this one. Could be something in your main routine is
grabbing the focus. I'm not sure what you mean by "automatically regain
focus". If it is destroyed that can't happen. If your talking about when
it is created, since the dialog is modeless (thus non-modal) the view can
grab back focus from it because they will run independently of each other.

HTH,

Tom

 
 
 

Modeless Dialog Boxes - Knowing when it terminates, Terminate without using delete Dlg and Getting input Focus

Post by Compute » Thu, 24 Nov 2005 10:37:16

Thanks Tom,

I could be too quick with the question. I need to check a few things.
I am in the process of changing my Property Pages to single Modeless
Dialogs.
It's just an odd thing how that when the mouse passes over the Dialog, it
has no effect.
It continues to do the OnMouseMove() in the view.

Thanks,
 
 
 

Modeless Dialog Boxes - Knowing when it terminates, Terminate without using delete Dlg and Getting input Focus

Post by Ajay Kalr » Thu, 24 Nov 2005 10:52:00

> 1. When I launch the Dialog box, how does one know when it ends?

Handle OnClose of your dialog. At this point the window exists so you can
get data from controls if you want. If you wait till the destructor is
called, all the controls of the dialog would have been destroyed.

dlg

I am not sure what you are doing here. YOu need to destroy the
dialog(window) as well. The C++ dialog object can then be deleted. You can
call DestroyWindow to destroy the dialog and then in OnPostNcDestroy, use
delete this. Read the following for more help:

http://www.yqcomputer.com/
 
 
 


Modeless Dialog Boxes - Knowing when it terminates, Terminate without using delete Dlg and Getting input Focus

Post by Compute » Thu, 24 Nov 2005 16:21:00

Yep. I think you nailed it!

A long time ago, I was looking for a way to only set the title of the window
once.
It was a Borland thing.
Instead of continually setting the title over and over again in OnMouseMove.
Some slick code captures the mouse input then tests to see if the Mouse is
in the View
Then has a Bool for only setting the title only once.

I didn't want to use OnFocus, but I might have to.
I'll have to test and see what happens if I add a SetCapture to the Dialog.
That might fix it.

Thanks,

//The Code
SetCapture(); // Capture the mouse input

if (Rect.PtInRect(point))
{ // Test if the pointer is on the window
if (m_PointerOnWnd != true)
{
GetDocument()->SetTitle(String);
m_PointerOnWnd = true;
//Also, Set all Keyboard Focus to this window
// SetFocus();
return TRUE;
}else{
return TRUE;
}
}
else
{
ReleaseCapture();
m_PointerOnWnd = false;
return FALSE;
}
 
 
 

Modeless Dialog Boxes - Knowing when it terminates, Terminate without using delete Dlg and Getting input Focus

Post by Joseph M. » Fri, 25 Nov 2005 07:52:48


***
That's your problem. My preference is to have the dialog be given a CWnd * of the window
to which it should report its termination. In the OnClose handler, I do a SendMessage to
this window of a user-defined message

void CMyView::LaunchDialog()
{
if(MyModelessDialog == NULL)
{ /* does not exist */
MyModelessDialog = new CMyModelessDialog;
if(!MyModelessDialog.Create(CMyModelessDialog::IDD, this))
{ /* failed */
delete MyModelessDialog;
MyModelessDialog = NULL;
return;
} /* failed */
MyModelessDialog->owner = this;
} /* does not exist */
else
{ /* already exists */
MyModelessDialog->Show(SW_SHOW);
if(MyModelessDialog->IsIconic())
MyModelessDialog->Show(SW_RESTORE);
MyModelessDialog->SetForegroundWindow();
} /* already exists */

void CMyModelessDialog::OnClose()
{
owner->SendMessage(UWM_DIALOG_CLOSING);
...rest of close code here
DestroyWindow();
}

viud CMyModelessDialog::PostNcDestroy()
{
delete this;
}

LRESULT CMyView::OnDialogClosing(WPARAM, LPARAM)
{
MyModelessDialog = NULL;
return 0;
}
****
***
See the PostNcDestroy handler, above
***
****
Not needed. Use PostNcDestroy
****
***
Because you didn't follow the correct protocol for deleting a modeless dialog
***
***
no.
***
****
You haven't said exactly what the problem is. I've never seen behavior like you describe,
and I do a lot of modeless dialogs.
****
Joseph M. Newcomer [MVP]
email: XXXX@XXXXX.COM
Web: http://www.yqcomputer.com/
MVP Tips: http://www.yqcomputer.com/
 
 
 

Modeless Dialog Boxes - Knowing when it terminates, Terminate without using delete Dlg and Getting input Focus

Post by Joseph M. » Fri, 25 Nov 2005 07:55:22

ee below...
On Tue, 22 Nov 2005 17:37:16 -0800, "Computer" < XXXX@XXXXX.COM > wrote:

***
And why is that surprising? Are ;you perhaps confused by the brain-dead behavior of
X-windows, where moving the mouse over an inactive window activates the window? One of
the worst misfeatures of that kludge is that moving a mouse over an inactive window will
activate the window.
***
Joseph M. Newcomer [MVP]
email: XXXX@XXXXX.COM
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
 
 
 

Modeless Dialog Boxes - Knowing when it terminates, Terminate without using delete Dlg and Getting input Focus

Post by Joseph M. » Fri, 25 Nov 2005 07:56:36

It is simpler to set the title when something happens to change the title, rather than on
every mouse-move event.

Use OnActivate instead of OnSetFocus.
joe



Joseph M. Newcomer [MVP]
email: XXXX@XXXXX.COM
Web: http://www.yqcomputer.com/
MVP Tips: http://www.yqcomputer.com/
 
 
 

Modeless Dialog Boxes - Knowing when it terminates, Terminate without using delete Dlg and Getting input Focus

Post by Compute » Fri, 25 Nov 2005 12:26:37

Cool, I was trying to figure out a way to keep the Dialog from being
launched a 2nd time.

Thanks very Much,
dbgrpt.c +1
 
 
 

Modeless Dialog Boxes - Knowing when it terminates, Terminate without using delete Dlg and Getting input Focus

Post by Compute » Fri, 25 Nov 2005 14:26:56

gt; ***
It looked cool, but acted really annoying as I remember.
I sort of wanted something just a bit different.
By moving the mouse, it would just show the title, not necessarily activate
the window.
I suppose there is no other way to do that, other than the SetCapture and
ReleaseCapture Method.

The thing is, I am using a CSplitterWnd for multiple Views.
There's no way to tell which view is which, without setting the title bar,
or some pop-up effect.
The only option I am left with is to actually clicking the View, or adding a
Title bar to each view.

I think I have an Idea.
In the Views base class, I will check the String.
If there is a match, don't set title again, else set the title and return a
BOOL.
Then, I would add GetDocument()->UpdateAllViews(); to reset the BOOL value
for the other Views.
Even draw some nice color border. Like X-Windows.

It's doable, but maybe later on.

Thanks,
"Joseph M. Newcomer" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...


 
 
 

Modeless Dialog Boxes - Knowing when it terminates, Terminate without using delete Dlg and Getting input Focus

Post by Compute » Fri, 25 Nov 2005 21:15:13

I did something a bit different from the code you posted.
I thought you might be interested.
I am using multiple Modeless dialog boxes.

//This is not needed.

//Here is where I made a change.
owner->SendMessage(UWM_DIALOG_CLOSING, (WPARAM)this);


if(MyModelessDialog == (CMyModelessDialog*)wParam)
{
delete MyModelessDialog ;
MyModelessDialog = NULL;
}


Thanks,
dbgrpt.c +1
 
 
 

Modeless Dialog Boxes - Knowing when it terminates, Terminate without using delete Dlg and Getting input Focus

Post by Joseph M. » Sun, 27 Nov 2005 04:08:56

Yes, that looks like a reasonable generalization. If I have multiple dialogs, I do
exactly that.
joe



Joseph M. Newcomer [MVP]
email: XXXX@XXXXX.COM
Web: http://www.yqcomputer.com/
MVP Tips: http://www.yqcomputer.com/
 
 
 

Modeless Dialog Boxes - Knowing when it terminates, Terminate without using delete Dlg and Getting input Focus

Post by Joseph M. » Sun, 27 Nov 2005 04:36:57

ee below...
On Wed, 23 Nov 2005 21:26:56 -0800, "Computer" < XXXX@XXXXX.COM > wrote:

****
Mouse hooks would work.
****
****
In the case of CView, I would actually expect to see the OnMouseMove notifications as the
mouse passed over each view. You were stating the problem as if it were separate windows,
and that ends up becoming a bit confusing as to what was really going on.
****
*****
Yes, the technique of not setting the title if it is the same is a common way to eliminate
flicker. But I see no particular value for a BOOL here. We're not talking about major
overhead, unless it is hard to compute the actual title.

My very first MFC project had this problem, and I tried to draw a border inside the view.
Real hard to do, because the view could scroll, and the border would scroll, too, which
was awkward and took more work than I should have to do it kind-of-right. In retrospect,
I should have had four border windows which were siblings of the view and arranged to
paint them as active or passive, and treated them using the layout method (something like
overriding RecalcLayout) so they would indicate which frame had the focus.
****
Joseph M. Newcomer [MVP]
email: XXXX@XXXXX.COM
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm