VS2010，MFCEditBrowseControl堆崩溃
我有一个简单的对话框，其中包含新的 MFC 浏览编辑控件。使用成员变量向导将该控件链接到“CMFCEditBrowseCtrl m_edit”。向导生成的映射看起来不错。
首次运行时，编辑控件会填充中文字符或有时是问号，然后在首次按下浏览按钮时或选择文件后崩溃。
应用程序因堆损坏失败而崩溃。
当我创建一个新的测试项目并执行相同的步骤时，一切正常 - 仅当我尝试在升级历史记录约为 VS2003 的较大旧项目中实现浏览编辑控件时才会出现问题 -> VS2005-> VS2008-> VS2010。
代码没有什么奇怪的，我怀疑它可能与项目清单或其他一些初始化指令/冲突有关。我已经从测试项目中复制并粘贴了 CWinApp::InitInstance 代码，希望能够揭示一些内容，但行为仍然相同。
有什么想法吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
经过一些进一步的调查，就在我放弃依赖此控件的代码时，我注意到一种解决方法可能是放置一个 CEdit 控件，而不是直接将 CMFCBrowseEditCtrl 放置在对话框中！然后在头文件中，将控件的成员变量类型CEdit替换为CMFCBrowseEditCtrl。我发现这很有效，因为我发现一些旧代码也使用这个控件，效果很好
也为我工作。>块引用
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
我认为这是因为一个错误导致它假设输入 CMFCEditBrowseCtrl 的任何文本都使用 Unicode 字符编码。因此，经常使用 ASCII（字符编码=“未设置”或项目设置中为空）的旧项目将会失败。
我现在遇到了同样的行为，可以通过使用如下代码来解决它：
ctrl.SetWindowText((LPTSTR)(LPCWSTR)CStringW(strvar));这会强制将 Unicode 字符串转换为控件，文本突然正确显示。
但是，我在垃圾收集时收到堆损坏错误。我认为这是因为它现在尝试释放该字符串，这次可能是作为 ASCII 而不是 Unicode。
所以我不确定除了将项目转换为 Unicode 之外还有什么方法可以获胜。对于一个旧的大型项目来说，这可能相当耗时。
更新：以下是来自 Microsoft Connect 的相关信息：错误 641662。显然，这种行为是根据设计而定的，因为 COMCTL v6 仅支持 Unicode，并且这是一个 COMCTL v6 控件。
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.