VS2010, MFCEditBrowseControl кучи сбой - PullRequest
Новая
       32

VS2010, MFCEditBrowseControl кучи сбой

1 голос
/ 12 января 2012

У меня есть простой диалог, который содержит новый элемент управления для просмотра MFC. Элемент управления был связан с CMFCEditBrowseCtrl m_edit с помощью мастера переменных-членов. Созданные мастером сопоставления выглядят нормально.

При первом запуске элемент управления для редактирования заполняется символами китайского типа или иногда с вопросительными знаками, а затем завершает работу либо при первом нажатии кнопки обзора, либо сразу после выбора файла.

Приложение вылетает с ошибкой повреждения кучи.

Когда я создаю новый тестовый проект и выполняю те же шаги, все работает нормально - проблема возникает только тогда, когда я пытаюсь реализовать элемент управления просмотра обзора в более старом старом проекте с историей обновления приблизительно VS2003 -> VS2005 -> VS2008 -> VS2010.

В коде нет ничего странного, и я подозреваю, что он может иметь отношение к манифесту проекта или какой-либо другой инструкции / конфликту инициализации. Я скопировал и вставил код CWinApp :: InitInstance из тестового проекта, надеясь, что это может что-то показать, но поведение остается тем же.

Есть идеи?

Ответы [ 2 ]

1 голос
/ 09 августа 2016

После некоторого дальнейшего изучения, когда я почти отказался от своего кода, полагаясь на этот элемент управления, я заметил, что одним из обходных путей может быть вместо размещения CMFCBrowseEditCtrl непосредственно в диалоговом окне, размещение элемента управления CEdit! А затем в заголовочном файле замените проверяемый элемент типа CEdit для элемента управления на CMFCBrowseEditCtrl. Я обнаружил, что это работает, так как я нашел старый код, также использующий этот элемент управления, который работал хорошо работал и для меня.> Blockquote

0 голосов
/ 04 декабря 2012

Я думаю, это потому, что ошибка заставляет его предположить, что любой текст, подаваемый в CMFCEditBrowseCtrl, использует кодировку символов Unicode.Поэтому старые проекты, которые часто используют ASCII (кодировка символов = «Не установлено» или просто пустые в настройках проекта), потерпят неудачу.

Я сейчас испытываю то же поведение и могу обойти это с помощью кодакак это: ctrl.SetWindowText((LPTSTR)(LPCWSTR)CStringW(strvar));

Это заставляет строку Юникода в элементе управления, и текст внезапно отображается правильно.

Однако я получаю ошибку повреждения кучи при сборке мусора.Я предполагаю, что это потому, что теперь он пытается освободить эту строку, возможно, как ASCII, а не Unicode, на этот раз.

Так что я не уверен, что здесь можно выиграть, кроме конвертации вашего проекта в Unicode.Что, вероятно, отнимает много времени для старого большого проекта.

Обновление: Вот информация об этом из Microsoft Connect: Ошибка 641662 .Очевидно, это поведение соответствует дизайну, поскольку COMCTL v6 доступен только для Unicode, а это элемент управления COMCTL v6.

...