У меня есть библиотека, созданная для проекта Windows рабочего стола. Это сделано в MFC VC ++ кем-то другим, и это работает правильно. Я буду использовать одну конкретную функцию из библиотеки в качестве примера для объяснения ситуации.
Пример функции выглядит так:
CString GetFulPath(); // .h file
В файле cpp
CString CwFolderBrowser::GetFullPath()
{
CString path;
if(this->M_pIDLIST!=NULL)
{
LPTSTR fullPath=path.GetBuffer(MAX_PATH);
::SHGetPathFromIDList(this->M_pIDLIST, fullPath); //ITEMIDLISTからパスを得る
path.ReleaseBuffer();
}
return path;
}
Теперь я могу включить эту библиотеку в свой проект и сделать что-нибудь вроде:
CwFolderBrowser cFolderBrowser;
if(cFolderBrowser.ShowDialog() == TRUE)
cPath = cFolderBrowser.GetFullPath();
Откроется диалоговое окно браузера папок, и я смогу выбрать папку. Он отлично работает в окнах рабочего стола.
В настоящее время я работаю на устройстве Windows CE. Мы преобразовали библиотеку для использования с Windows CE, удалив неподдерживаемые функции и прочее. Библиотека компилируется и строится правильно, без ошибок.
Затем я создаю проект интеллектуального устройства MFC, включаю преобразованную библиотеку, ее h-файл и файлы lib и устанавливаю соответствующие каталоги для dll. Проект строится нормально. Я также могу правильно # включить файл h библиотеки.
Проблема возникает, как только я вызываю функцию GetFullPath:
cPath = cFolderBrowser.GetFullPath();
Это дает мне неразрешенную ошибку внешней ссылки! Intellisense показывает эту функцию в своем списке, и я могу выбрать ее и все остальное. Но тщетно.
Как ни странно, если я изменю библиотеку и изменю подпись GetFullPath (), как показано ниже,
LPCTSTR GetFulPath(); // .h file LPCTSTR instead of CString
В файле cpp
LPCTSTR CwFolderBrowser::GetFullPath() // Return type changed to LPCTSTR
{ // instead of CString
... // Body modified accordingly
}
тогда неразрешенная ошибка внешней ссылки исчезает, и она работает!
Я озадачен этим странным поведением, потому что я могу нормально использовать CString в проекте MFC Smart Device, и ошибок нет. Ошибка ссылки появляется только тогда, когда я пытаюсь вызвать функции из библиотеки (и других подобных библиотек) dll. В то же время BOOL, int и т. Д., Похоже, не имеют проблем как возвращаемые типы функций.
Конечно, я могу пройтись по каждой библиотеке и изменить каждый экземпляр CString return на LPCTSTR, но это было бы очень большим изменением. Я хотел бы знать, почему CString отлично работает в проекте, а также dll на рабочем столе, тогда как на Win CE он работает в проекте, но не в DLL (в то же время сама DLL компилируется нормально без ошибок, если она использует CString или LPCTSTR!).
Итак, в основном, Я хотел бы сохранить функцию CString, если это возможно, и хотел бы знать причину, по которой это происходит. Точно такая же ошибка возникает и в других библиотеках.
Любая помощь приветствуется. Спасибо.
ОБНОВЛЕНИЕ: Я видел страницу об ATL и MFC 7.0, на которой говорилось об использовании параметра / Zc: wchat_t. Я проверил проект Dll, а также свое приложение. Оба используют ту же опцию «Обрабатывать wchar_t как встроенный тип» как «Да». Итак, этот вариант подходит. Далее, как я уже упоминал выше, изменение функции return на LPCTSTR работает. Ошибка исчезает. Все идет хорошо, пока я не конвертирую возвращенный LPCTSTR обратно в CString. CString оказывается пустым / нулевым. Это происходит как внутри самого кода dll, так и в коде моего приложения.
ОБНОВЛЕНИЕ 2: благодаря Майклу и Коди я изменил функцию на LPCTSTR и убедился, что значения не выходят за рамки, прежде чем я смогу использовать их, как они предлагали. Теперь проблема пустого / нулевого значения решена, и я могу правильно получить значения пути.
Остается проблема в том, что мне нужно преобразовать все функции CString в LPCTSTR, что не совсем возможно. Я хотел бы сохранить функции как CString.
