Click here to Skip to main content
15,867,308 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hey Guys,

I have an interesting question regarding migrating a 32 bit MFC project on VS 2008 to 64 bit on VS 2017.

The problem revolves around the following example code

C++
CMyDialog *dlg;
CString myString;

dlg = new CMyDialog(NULL);
myString = _T("test");

dlg->m_dlg_string = myString;

if(dlg->DoModal() == IDOK)
{
     myString = dlg->m_dlg_string;
}

dlg->~CMyDialog()


Here is the rub. On the 32 bit MFC VS 2008 project this code snippet is bullet proof. With the 64 bit conversion into VS 2017 this is throwing exceptions all over the place.

I realise this might be asking how long a piece of string is but does anyone have any ideas?

I look forward to everyone responses and thank you in advance.

P.S - I'm using VS 2017 15.9

What I have tried:

What I have tried to do to resolve this is the following,
*Re-ordering the CString declaration order. That was a glorified band aid
*Creating a fresh dialog in the VS 2017 project. What shocked me was it had the same result but the thing that caused the exception was the string assignment.
Posted
Updated 1-Aug-19 22:21pm
Comments
Richard MacCutchan 1-Aug-19 9:38am    
"throwing exceptions all over the place."
Sorry, but we cannot guess what that means. What exceptions do you see and which line of code throws them?
Richard MacCutchan 1-Aug-19 9:44am    
Why are you making an explicit call to the destructor, instead of using the delete operator?

I took the liberty to create a default MFC Dialog based project. I am using Visual Studio 2017 Enterprise. I then inserted your code.
Here is how your code should look like (and of course, you should not call the destructor and also nothing to do with x86 Vs. x64).

CString myString;

dlg = new CMyDialog(NULL);
myString = _T("test");

dlg.m_slg_string = myString;
m_pMainWnd = &dlg;
INT_PTR nResponse = dlg.DoModal();
if (nResponse == IDOK)
{
    myString = dlg->m_dlg_string;
    // TODO: Place code here to handle when the dialog is
    //  dismissed with OK
}
else if (nResponse == IDCANCEL)
{
    // TODO: Place code here to handle when the dialog is
    //  dismissed with Cancel
}
else if (nResponse == -1)
{
    TRACE(traceAppMsg, 0, "Warning: dialog creation failed, so application is terminating unexpectedly.\n");
    TRACE(traceAppMsg, 0, "Warning: if you are using MFC controls on the dialog, you cannot #define _AFX_NO_MFC_CONTROLS_IN_DIALOGS.\n");
}
 
Share this answer
 
v2
Comments
Rick York 1-Aug-19 17:52pm    
Why create an application dialog on the heap? That means it is a pointer and you have to use -> to access it everywhere, which you didn't do in your solution.

It could be a plain, old, stack variable just as easily if not more so.
D_code_writer 1-Aug-19 20:27pm    
Hey Guys,

Many thanks for all this.

The exception that it is throwing is the ntdll.dll dll.

However I will give both this sample and delete code a try.

Many thanks
Michael Haephrati 2-Aug-19 5:02am    
Basically, what I did is to use the Microsoft default Dialog based project source code, and that's how the source code looks like when you create a new MFC Dialog based project.
Hey Guys,

I figured out a work around that worked.

Where it fell down in the was the assignment in the variables. Getting them from the dialog was fine. Here is the code snippet,

C++
CMyDialog dlg;
CString MyString;

MyString = _T("test");

dlg.SetState_m_dlg_string(MyString) // Write a void function internally that writes the variable

if(dlg.DoModal() == IDOK)
{
     MyString = dlg.m_dlg_string;
}


Pretty weird I know but a win is a win and I'll take it. Thanks everyone again for their help.
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900