STL incompatible with Windows Forms?
-
I have a strange problem that has been driving me up the wall. I created a SSCCE that shows my problem. Compile this with
cl /EHsc /clr <filename>
:#using <mscorlib.dll>
#using <System.dll>
#using <System.Windows.Forms.dll>#include <iostream>
int main()
{
using System::Windows::Forms::DialogResult;
using System::Windows::Forms::FolderBrowserDialog;
using System::Windows::Forms::MessageBox;double d; std::cin >> d; FolderBrowserDialog\* fb = new FolderBrowserDialog; if (fb->ShowDialog() == DialogResult::OK) { MessageBox::Show(fb->SelectedPath); }
}
When I run this program as is, after entering a number on the command line, the FolderBrowserDialog comes up blank. However, if I comment out the
std::cin >> d;
line, then the FolderBrowserDialog works fine. Does this happen for anybody else? Or am I misusing the mixture of managed and unmanaged code? I am using VS .NET 2003 on Windows XP SP2, with the .NET 1.1 Framework.-- Marcus Kwok
-
I have a strange problem that has been driving me up the wall. I created a SSCCE that shows my problem. Compile this with
cl /EHsc /clr <filename>
:#using <mscorlib.dll>
#using <System.dll>
#using <System.Windows.Forms.dll>#include <iostream>
int main()
{
using System::Windows::Forms::DialogResult;
using System::Windows::Forms::FolderBrowserDialog;
using System::Windows::Forms::MessageBox;double d; std::cin >> d; FolderBrowserDialog\* fb = new FolderBrowserDialog; if (fb->ShowDialog() == DialogResult::OK) { MessageBox::Show(fb->SelectedPath); }
}
When I run this program as is, after entering a number on the command line, the FolderBrowserDialog comes up blank. However, if I comment out the
std::cin >> d;
line, then the FolderBrowserDialog works fine. Does this happen for anybody else? Or am I misusing the mixture of managed and unmanaged code? I am using VS .NET 2003 on Windows XP SP2, with the .NET 1.1 Framework.-- Marcus Kwok
OK, I found a solution that seems to work. In the article Mix and Match: Integrate Windows Forms Into Your MFC Applications Through C++ Interop (http://msdn.microsoft.com/msdnmag/issues/06/05/MixAndMatch/[^]), I found this piece of advice:
If you compile with the /clr option, your code implicitly depends on the multithreaded DLL version of the C runtime libraries (CRT). This means that all files in your project—even those compiled without /clr—must use the multithreaded DLL version of the CRT.
Adding
/MD
to the compile command seems to fix it. Incidentally, this also seems to fix my earlier problems (here and here).-- Marcus Kwok