Разработка ведется на C/C++ поверх MS SDK.
Часть С++ XLL выглядит следующим образом:
__declspec(dllexport) LPWSTR WINAPI xlGetLang(LPSTR in_key) {
try {
static XLOPER12 lang;
static size_t buffer_size = 0;
static wchar_t * buffer = NULL;
std::wstring unicode_str;
// This step get the unicode string assigned to unicode_str
// with the key in_key from internal dictionary.
pms::get_instance()->get_lang(in_key, unicode_str);
// over
size_t msg_len = unicode_str.length();
// This step checks whether we need to incraese the buffer
// for the unicode string to be returned.
if (buffer_size == 0) {
buffer = (LPWSTR) malloc(sizeof(wchar_t) * (msg_len + 1));
buffer_size = msg_len;
} else if (buffer_size < msg_len) {
buffer = (LPWSTR) realloc(buffer, sizeof(wchar_t) * (msg_len + 1));
buffer_size = msg_len;
}
// over
wcsncpy(buffer, unicode_str.c_str(), msg_len);
buffer[msg_len] = 0;
return buffer;
}
catch (...) {
;
}
}
Сбой Excel VBA в строке Application.Run:
Dim var As String
var = Application.Run("xGetLang", key)
Комбинация XLL и VBA работает нормально, когда XLL возвращает короткую строку юникода (т. е. с wchar_t длины 6), но начнется сбой, когда будет возвращена более длинная строка юникода (т. е. с wchar_t длины 8) (один из таких случаев — «OFFICE: ").
Сбойная среда — Excel 2007 или Excel 2010 в Vista. Однако эта комбинация XLL и VBA работает без проблем на другом компьютере Excel 2007 на XP.
Я попытался поместить блок try catch в функцию надстройки XLL. Исключение не поймано. Я также пытался поставить оператор ON ERROR в коде VBA, он тоже ничего не ловит. Похоже, сбой происходит между оператором возврата XLL и статусом excel VBA Application.Run. Я пытался проверить работающий стек, когда он падает. это выглядит следующим образом:
- NTDLL.DLL (точка сбоя из-за записи в память 0X000000000 )
- Kernal32.dll
- XLL надстройка DLL
- Excel.exe
Кто-нибудь знает?