I have a simple dialog that contains the new MFC browse edit control. The control was linked to 'CMFCEditBrowseCtrl m_edit' using the member variable wizard. The wizard generated mappings seem fine.
On first run, the edit control is populated with chinese type characters or sometimes question marks, and then crashes either when the browse button is first pressed, or as soon as a file has been selected.
The app crashes with a heap corruption failure.
When I create a new test project and perform the same steps, all works fine - the problem only occurs when I try to implement the browse edit control in a larger older project with an upgrade history of approx VS2003 -> VS2005 -> VS2008 -> VS2010.
There is nothing odd about the code, and I suspect it might have something to do with the project manifest or some other init instruction / conflict. I have copied and pasted the CWinApp::InitInstance code from the test project hoping that that might reveal something, but the behaviour is still the same.
Any ideas?
After some further investigation, just about I was abandoning my code relying on this control, I noticed that one workaround may be to instead of placing CMFCBrowseEditCtrl directly in the dialog box, place a CEdit control! And then in the header file, replace the member veriable type CEdit for the control with CMFCBrowseEditCtrl. I discovered this worked as I found some old code also using this control, which worked well
worked for me as well.> Blockquote
I think this is because a bug causes it to assume that any text fed into the CMFCEditBrowseCtrl is using the Unicode character encoding. So older projects which often use ASCII (Character Encoding = "Not Set" or simply empty in the Project Settings) will fail.
I'm experiencing the same behavior right now, and could work around it by with code like this: ctrl.SetWindowText((LPTSTR)(LPCWSTR)CStringW(strvar));
This forces a Unicode string into the control, and the text suddenly displays properly.
However, I then get a heap corruption error upon garbage collection. I assume this is because it now tries to free that string, perhaps as an ASCII and not Unicode this time.
So I'm not sure there is any way to win here, except converting your project to Unicode. Which is likely to be rather time consuming for an old, large project.
Update: Here's information on this from Microsoft Connect: Bug 641662. Apparently this behavior is per design since COMCTL v6 is Unicode-only, and this is a COMCTL v6 control.
