Board index » Visual Studio » Need help resolving modeless dialog issue

Visual Studio351
Hi,



I have a weird problem that only shows up in a release build, and not

in debug. I have a modeless dialog I'm launching from a menu. It

opens up fine in debug mode, works great and while it needs tinkering,

it's fine.



I run into problems on a release build, though. The first time I

click to launch the dialog window (which runs this code:)



CPrgEditorDialog* dlg = new CPrgEditorDialog;

dlg->ptrToMain = m_hWnd;

dlg->ShowWindow(SW_SHOW);



The modeless dialog doesn't show up. If I navigate through the menu

and select it again, it opens correctly. Any attempts after that open

a new window on the first try.



It's just like that first one gets fried as soon as I open it, but

only in release mode. I'll be happy to tell you more, I know this is

slight information to go on... but I don't know where to even begin

looking on this one.



Thanks,

~Scoots


-

Where do you call create on your dialog?



dlg->Create(CPrgEditorDialog::IDD,this);



The easiest thing to use for debuging in Release mode is MessageBox. Use

MessageBox to make sure that everything is going as you planned during your

dialog creation.



AliR.



"Scoots" <linkingfire@msn.com>wrote in message



-

happened. It occurs in the:

CPrgEditorDialog* dlg = new CPrgEditorDialog;



under a debug build.



I try that message box and see if it ever makes it without an explicit

create call under release.

~Scoots

On Jul 30, 4:41 pm, "AliR \(VC++ MVP\)" <A...@online.nospam>wrote:



-

I just set a breakpoint and then stepped out to see where it

happened. It occurs in the:

CPrgEditorDialog* dlg = new CPrgEditorDialog;



under a debug build.





I tried that message box and it did go into Create both times.

~Scoots



On Jul 30, 4:41 pm, "AliR \(VC++ MVP\)" <A...@online.nospam>wrote:



-

oh, and the Create explicit is there, I just didn't see it. It's in

my constructor.

Create(IDD_ProgEditor, NULL);



-

Where did you step out to? Were you taking a break? I just got done

answering your other question down the list and your response was just as

confusing as this one.



I am not trying to be mean or anything, I am just trying to get you to

explain things a little better with a little more detail so that some one

can actually help you with your problems.



I thought you said that everything worked fine in Debug mode?



When you are talking about creating a dialog and things are not working, you

can't show some code that doesn't even call Create on the dialog. You have

to either explain that where its happening or show some code that calls

create on the dialog.



Which brings me to something else that I was wondering about: Who is

deleting the dialog when the user is done with it? Does the dialog delete

itself?



AliR.



"Scoots" <linkingfire@msn.com>wrote in message



-

Can you post the dialogs constructor, DoDataExchange and OnInitDialog?



AliR.





"Scoots" <linkingfire@msn.com>wrote in message



-

On Jul 30, 5:10 pm, "AliR \(VC++ MVP\)" <A...@online.nospam>wrote:

The constructor is excessively long (~400 lines), so I'll try to post

only what is relevant.



CPrgEditorDialog::CPrgEditorDialog(CWnd* pParent /* = NULL*/)

: CDialog(CPrgEditorDialog::IDD, pParent)

{

//{{AFX_DATA_INIT(CPrgEditorDialog)

m_csListCommands = _T("");

m_csListModels = _T("");

m_csListVariables = _T("");

m_csLblCommands = _T("");

m_csLblVariables = _T("");

m_InsertionEditString = _T("");

//}}AFX_DATA_INIT

AfxInitRichEdit();

//DragAcceptFiles(true);

RECT* prect = new RECT;

if (!Create(IDD_ProgEditor, NULL))

MessageBox(_T("YEP, failed it"),_T("YURP"),MB_OK);

this->SetWindowPos(&wndTop, 0, 0, m_nDefsizex, m_nDefsizey,

SWP_SHOWWINDOW);



void CPrgEditorDialog::DoDataExchange(CDataExchange* pDX)

{ //Most of these are irrelevant, as I do not use them.

CDialog::DoDataExchange(pDX);

//{{AFX_DATA_MAP(CPrgEditorDialog)

DDX_Control(pDX, IDC_VerboseOut, m_VerboseOut);

DDX_Control(pDX, IDC_CHECKFunctions, m_CheckFunctions);

DDX_Control(pDX, IDC_STATICModels, m_lblModels);

DDX_Control(pDX, IDC_CHECKVariables, m_CheckVariables);

DDX_Control(pDX, IDC_CHECKSyntax, m_CheckSyntax);

DDX_Control(pDX, IDC_CHECKNumbers, m_CheckNumbers);

DDX_Control(pDX, IDC_CHECKOperators, m_CheckOperators);

DDX_Control(pDX, IDC_CHECKControls, m_CheckControls);

DDX_Control(pDX, IDC_CHECKCommands, m_CheckCommands);

DDX_Control(pDX, IDC_RICHEDIT1, m_REditControl);

DDX_Control(pDX, IDC_STATICVars, m_lblVars);

DDX_Control(pDX, IDC_executeButton, m_btnExecute);

DDX_Control(pDX, IDC_RecheckButton, m_btnSyntax);

DDX_Control(pDX, IDC_PROGRESS1, m_progbarcontrol);

DDX_Control(pDX, IDC_LIST4, m_ListVariables);

DDX_Control(pDX, IDC_LIST1, m_ListCommands);

DDX_Control(pDX, IDC_TLMarker, m_TLMarker);

DDX_Control(pDX, IDC_InsertionEdit, m_InsertionEditControl);

DDX_Control(pDX, IDC_STATIC2, m_lblVariableInfo);

DDX_Control(pDX, IDC_STATIC1, m_lblCommandInfo);

DDX_Control(pDX, IDC_LIST3, m_ListModels);

DDX_LBString(pDX, IDC_LIST1, m_csListCommands);

DDX_LBString(pDX, IDC_LIST3, m_csListModels);

DDX_LBString(pDX, IDC_LIST4, m_csListVariables);

DDX_Text(pDX, IDC_STATIC1, m_csLblCommands);

DDX_Text(pDX, IDC_STATIC2, m_csLblVariables);

DDX_Text(pDX, IDC_InsertionEdit, m_InsertionEditString);

//}}AFX_DATA_MAP

}



There is no overloaded OnInitDialog.



-

On Jul 30, 5:10 pm, "AliR \(VC++ MVP\)" <A...@online.nospam>wrote:









The constructor is excessively long (~400 lines), so I'll try to post

only what is relevant.



CPrgEditorDialog::CPrgEditorDialog(CWnd* pParent /* = NULL*/)

: CDialog(CPrgEditorDialog::IDD, pParent)

{

//{{AFX_DATA_INIT(CPrgEditorDialog)

m_csListCommands = _T("");

m_csListModels = _T("");

m_csListVariables = _T("");

m_csLblCommands = _T("");

m_csLblVariables = _T("");

m_InsertionEditString = _T("");

//}}AFX_DATA_INIT

AfxInitRichEdit();

//DragAcceptFiles(true);

RECT* prect = new RECT;

if (!Create(IDD_ProgEditor, NULL))

MessageBox(_T("YEP, failed it"),_T("YURP"),MB_OK);

this->SetWindowPos(&wndTop, 0, 0, m_nDefsizex, m_nDefsizey,

SWP_SHOWWINDOW);

//continues, but with local specific code.

}





void CPrgEditorDialog::DoDataExchange(CDataExchange* pDX)

{ //Most of these are irrelevant, as I do not use them.

CDialog::DoDataExchange(pDX);

//{{AFX_DATA_MAP(CPrgEditorDialog)

DDX_Control(pDX, IDC_VerboseOut, m_VerboseOut);

DDX_Control(pDX, IDC_CHECKFunctions, m_CheckFunctions);

DDX_Control(pDX, IDC_STATICModels, m_lblModels);

DDX_Control(pDX, IDC_CHECKVariables, m_CheckVariables);

DDX_Control(pDX, IDC_CHECKSyntax, m_CheckSyntax);

DDX_Control(pDX, IDC_CHECKNumbers, m_CheckNumbers);

DDX_Control(pDX, IDC_CHECKOperators, m_CheckOperators);

DDX_Control(pDX, IDC_CHECKControls, m_CheckControls);

DDX_Control(pDX, IDC_CHECKCommands, m_CheckCommands);

DDX_Control(pDX, IDC_RICHEDIT1, m_REditControl);

DDX_Control(pDX, IDC_STATICVars, m_lblVars);

DDX_Control(pDX, IDC_executeButton, m_btnExecute);

DDX_Control(pDX, IDC_RecheckButton, m_btnSyntax);

DDX_Control(pDX, IDC_PROGRESS1, m_progbarcontrol);

DDX_Control(pDX, IDC_LIST4, m_ListVariables);

DDX_Control(pDX, IDC_LIST1, m_ListCommands);

DDX_Control(pDX, IDC_TLMarker, m_TLMarker);

DDX_Control(pDX, IDC_InsertionEdit, m_InsertionEditControl);

DDX_Control(pDX, IDC_STATIC2, m_lblVariableInfo);

DDX_Control(pDX, IDC_STATIC1, m_lblCommandInfo);

DDX_Control(pDX, IDC_LIST3, m_ListModels);

DDX_LBString(pDX, IDC_LIST1, m_csListCommands);

DDX_LBString(pDX, IDC_LIST3, m_csListModels);

DDX_LBString(pDX, IDC_LIST4, m_csListVariables);

DDX_Text(pDX, IDC_STATIC1, m_csLblCommands);

DDX_Text(pDX, IDC_STATIC2, m_csLblVariables);

DDX_Text(pDX, IDC_InsertionEdit, m_InsertionEditString);

//}}AFX_DATA_MAP







}





There is no overloaded OnInitDialog.



And sorry, I am NOT a windows programmer, I've just been kinda tossed

into it. Everything does work fine in the debug mode. You asked

where the create happened and I didn't see it, but it IS called, just

from the window constructor. To handle deletions, I overload

PostNCDestroy:



void CPrgEditorDialog::PostNcDestroy()

{

//local deletions.

delete this;

}



-

On Mon, 30 Jul 2007 13:32:41 -0700, Scoots <linkingfire@msn.com>wrote:



You did not actually create a dialog here. You created a new instance of the C++ object,

but not an instance of the dialog itself.



You should do

dlg->Create(CPrgEditorDlg::IDD, this);



Note that by specifying 'this', you make the parent be the current window, so you don't

need ot have a ptrToMain (and if you DID have a ptrToMain, why is it an HWND instead of

being a CWnd * and write

dlg->ptrToMain = this;

since an HWND is not a ptr, and therefore using HN incorrectly is both misleading and a

source of future errors.



In the dialog, if you need to communicate to the window, you can write

GetParent()->SendMessage(...);

instead of

::SendMessage(ptrToMain, ...);

****

You have not shown enough code to make it clear what happens if you call it a second time;

you only showed the code that handles it for the first time. You would need to show all

relevant code for the creation.

****

See my essay on Surviving the Release Version in my MVP Tips site.

joe

****

email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

-

Generally, avoid using the IDD_ name, and just use classname::IDD, or if this is in the

constructor, you can just use IDD. It means you never have to know the ID of the dialog.



Note that the constructor takes a parameter which is the parent, so why do you use NULL

here instead of the parent window pointer (a CWnd *)? Then you wouldn't need to have the

badly-named ptrToMain (which isn't a ptr)

joe

On Mon, 30 Jul 2007 14:04:25 -0700, Scoots <linkingfire@msn.com>wrote:



email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

-

See below...

On Mon, 30 Jul 2007 14:15:59 -0700, Scoots <linkingfire@msn.com>wrote:



if(!Create(IDD, pParent))

*****

Do you really mean it to be positioned in the top left corner? Note that if you do the

SWP_SHOWWINDOW here, you shouldn't need to call the ShowWindow(SW_SHOW) elsewhere.

joe

****

email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

-

Thank you. The problem is still there, but what you've said does make

sense. I've switched to the way you suggest, and moved my local

definitions to the OnInitDialog, since the window doesn't exist in the

constructor anymore.



The reason why I did it that way? The example I used to do a modeless

dialog did it that way. I'm not a windows coder, I'm a c++ coder, so

I followed the example and it worked, *shrug*. That second show

window was redundant, on purpose. I was trying to force the window to

show and return an error, but no luck there.



Hopefully, this is much closer to being correct:



void CMainFrame::OnOpenProgBuilder()

{

CPrgEditorDialog* dlg = new CPrgEditorDialog;

dlg->Create(CPrgEditorDialog::IDD, this);

dlg->ShowWindow(SW_SHOW);

}



CPrgEditorDialog::CPrgEditorDialog(CWnd* pParent )

: CDialog(CPrgEditorDialog::IDD, pParent)

{

//{{AFX_DATA_INIT(CPrgEditorDialog)

m_csListCommands = _T("");

m_csListModels = _T("");

m_csListVariables = _T("");

m_csLblCommands = _T("");

m_csLblVariables = _T("");

m_InsertionEditString = _T("");

//}}AFX_DATA_INIT

AfxInitRichEdit();

//DragAcceptFiles(true);

}



BOOL CPrgEditorDialog::OnInitDialog()

{

CDialog::OnInitDialog();



// my local variable declarations. ~ 400 lines worth.



return TRUE; // return TRUE unless you set the focus to a

control

// EXCEPTION: OCX Property Pages should return FALSE

}





My problem still exists, and I thank you for helping me get the window

creation adjusted. As to your comment, Joseph, you HAVE seen the code

pertaining to opening the window a second time. It runs the same

code. It does nothing different (except that, obviously, it is). I

placed a message box in the PostNCDestroy and it is not recieving a

termination signal there until I manually close it. However, at the

same time, I realized that despite there being no memory leaks in the

program, closing the window via the windows titlebar doesn't call

this, so it is still possible the window is recieving a close signal,

and I'll see if I can't hunt that down.



-

After setting a message box in OnCancel, OnClose, and PostNcDestroy(),

no close message is being sent to the window, so I'm still not sure

what's causing this failure.





I appreciate your help,

~Scoots



-

Can you email your project or is it too big?



AliR.



"Scoots" <linkingfire@msn.com>wrote in message



-

See below...

On Tue, 31 Jul 2007 05:49:32 -0700, Scoots <linkingfire@msn.com>wrote:



This does not belong here. If the dialog contains rich-edit control, without this call

having been executed before the DoModal or Create (in your case), the dialog creation will

fail. So if it is needed, this is far too late to deal with it.



Also, depending on which version of VS you are using, you more likely want to call

AfxInitRichEdit2() back in your InitInstance handler.

*****

Although if it takes 400 lines to initialize the variables, you might have too many of

them. I did a quick survey of something like 150 dialogs I've written, and the absolutely

most complex one (does window positioning, creates fonts, has dozens of controls, controls

being initialized from the Registry, etc.) had about 150 lines. So something with that

many member variables is a little scary, to say the least.

*****

The usual technique goes something like this:



CMyDialog * modeless;



contructor:

modeless = NULL



menu action:



if(modeless == NULL)

{

modeless = new CMyDialog;

modeles->Create(CMyDialog::IDD, this);

modeless->ShowWindow(SW_SHOW);

}

else

{

if(modeless->IsIconized())

modeless->ShowWindow(SW_RESTORE);

if(!modeless->IsWindowVisible())

modeless->ShowWindow(SW_SHOW);

}



A common technique is to allow a modeless dialog to be minimized or hidden instead of

being closed. This does require that the OnDestroy post a message back to the parent

indicating that the variable should be reset to NULL.



An alternative is that the menu item is disabled if modeless is non-NULL, and again,

during the OnDestroy, a message is posted back to the parent to cause the variable to be

reset to NULL, and there is an UpdateCommandUI handler for the menu that says

pCmdUI->Enable(modeless == NULL);

In that case, the second case of restore/hide is not needed.



So that's why I was asking about the "second time" event, since it was not clear what

would happen if the code was invoked while the dialog was already active, or even if it

could be.

*****

Yes, if you create a modeless dialog, you should really make sure you destroy it yourself,

e.g.,

void CModelessOwner::OnDestroy()

{

if(modeless != NULL)

modeless->DestroyWindow();

}



Note also that not getting the messagebox does not prove the event did not happen; if you

are destroying the main app, it might be destroying all the child windows, but MFC has

mode flags to indicate whether or not messageboxes (or other windows) can be created. So

relying on messagebox during a shutdown is problematic. I'd trust a breakpoint first.

joe

*****

Joseph M. Newcomer [MVP]

email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

-

Note that if you call DestroyWindow, no WM_CLOSE message is sent. You will only see the

WM_DESTROY message.

joe



On Tue, 31 Jul 2007 07:38:35 -0700, Scoots <linkingfire@msn.com>wrote:



email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

-

I'll try to answer the best that I can in sequential order.



Unfortunately, AliR, I can't. The entire project is quite large and

requires the use of an external security keys and dlls. I'm only

working on a small portion, largely limited to this small portion and

what it does, with the exceptions of being able to inject small

amounts of code to open the window, etc



As to the rather large initDialog, I suppose I stated that somewhat

misleading. The number of variables isn't that large, I'm currently

populating a keyword map inside of it (shortly to be moved to another

method, anyway).



I've gone through, and placed messages everywhere, overrode OnCancel,

OnClose, and PostNcDestroy with messages, and these do trigger

correctly when I close the window manually. I get no such message

when the first window, which does flash up for the tiniest portion of

a second. So I'm pretty sure it's not catching a rogue termination.



The idea of showing and hiding occured to me, and due to a second

problem I may persue that, but for now, fully closing the window upon

closing is ideal. The reason is this is an interactive panel that is

part of a larger program that allows multiple user permissions, and

forcing the window to open and populate it's members with only what is

applicable to that user level was desirable. I'm sure this can be

replicated upon showing the window, and it's something worth

considering. Also, allowing multiple editing windows might not be a

bad thing in this situation.



Hence, if it's not the problem, I'd like to keep multiple windows at a

time. If that's the problem though, I'd rather limit to one window

than have the user think the program is broken. I'll keep trying, I

think it may be something internal to our project (but not my window,

though that's always a possibility), and our graphics libraries. It

just doesn't seem like that would interfere with a modeless dialog

window.



Cheers,

~Scoots



-