Thread: C++ console application works; Excel crashes when using the same code.

Compilers will decorate function names based on linkage, calling convention, and whatever else (it's all compiler dependent) - Stdcall and DLL tools of MSVC and MinGW

VB[A] wants stdcall but with no decoration (same as most all Win32 API DLL's). The normal way to achieve that is with a DEF file. "--add-stdcall-alias" allows you to skip using a DEF file.

>> Now I'm going back to the old BSTR problem
Does the code from post #11 work?

gg

Originally Posted by MSDN

... Functions should return types that VBA can recognize ByVal. This means that some types are more easily returned by modifying arguments in place: strings, arrays, user-defined types, and objects.
...
To return a byte string to VBA from a DLL, you should modify a byte-string BSTR argument in place. For this to work, you must declare the DLL function as taking a pointer to a pointer to the BSTR and in your C/C++ code, and declare the argument in the VBA code as ‘ByRef varg As String’.

You should only handle strings that are passed in these ways from VBA using the OLE BSTR string functions to avoid memory-related problems.

So MSDN prefers that you return string by reference. But I see plenty of examples returning BSTR's to VB[A] (like this:Financial applications using Excel ... - Google Books)

I may of incorrectly assumed that the given BSTR will be null-terminated. Try out these functions and see what you get:

Code:

BSTR WINAPI string_test1()
{
    const char *s = "Testing 123";
    return SysAllocStringByteLen(s, strlen(s));
}

BSTR WINAPI string_test2(BSTR stringVar)
{
    const size_t len = SysStringByteLen(stringVar);
    const char *begin = (const char*)stringVar;
    const char *end = begin + len;
    
    std::string buffer(begin, end);
	
    return SysAllocStringByteLen(buffer.c_str(), len);
}

gg

Originally Posted by laimaretto

Actually, I've tried this as well ...

Code:

BSTR string_ex(BSTR stringVar)
{
    string buffer((char*)stringVar);
    // code. here we work with 'buffer'. once done
    // copy its content to 'out_string'
    string out_string=buffer;

    // conversion from std::string to LPCSTR
    int str_len = out_string.length();
    LPCSTR lpcstr_out_string;
    lpcstr_out_string=out_string.c_str();

	return SysAllocStringByteLen(out_string.c_str(),str_len);

}

It tried to use a LPCSTR string since the first parameter of the function SysAllocStringByteLen is LPCSTR ... but the result is the same: I always get the first char of the string .... :-S

rgds!

lucas

Well, then start with the easy stuff.... is out_string.length() what you expect it to be? For I am suspicious of the (char *) cast at the beginning, as a BSTR starts with the size of the string, right? So you'll probably have one byte of ... something, then some zeros, which would kill your char*-style-string dead. EDIT: No, I'm wrong, the pointer points to the beginning of the data. BUT BSTRs are also Unicode, or at least MSDN says "May contain multiple embedded null characters" which would be bad.

string_test1() only shows a "T"?
Are you using .TLB to import the functions on the VBA side?
Are you using "Variant" as the string type on the VBA side?

>> string buffer((char*)stringVar);
This assumes that stringVar is a NULL terminated C-string. I do not know if that is a correct assumption.

gg

How to: Convert Between Various String Types

If you have access to CComBSTR I would use that. And read about the conversions

Excel is not treating your returned BSTR as an ANSI string. The UTF16-LE form of "敔瑳湩⁧㈱3" comes out as "Testing 123" when you just look at the bytes.

string_test2() is basically doing a "memcpy" of the original string. So Ansi or Unicode, you get the same result.

Originally Posted by Codeplug

Are you using .TLB to import the functions on the VBA side?
Are you using "Variant" as the string type on the VBA side?

If the answer is yes to either, then you will get Unicode BSTR's - not Ansi.

It almost seems like the BSTR's you're receiving are Unicode BSTR's. And the BSTR you return is interpreted as a Unicode BSTR. Can you explain exactly how you are calling and and displaying the results in Excel? And what version of Excel? And answer the two quoted questions.

gg

I took a look at a project like this that I've done myself a year ago.
I got it working by passing a string to VBA via a callback function.
How did I do it?

I had a prototype that looked like:
typedef void* (__stdcall StrSetRangeFncPtr)(Worksheet Sheet, VBString Addr, VBString What);
Which in VBA was:
Sub StrSetRange(ByVal Sheet As Worksheet, ByVal Addr As String, ByVal What As String)

Where VBString = BSTR.
It was called like so:

g_StrSetRange(Sheet, CComVBString(Cell/*.c_str()*/), str);
Where Cell is a string (type: const char*).

Hope that helps in some way.
Oh, and CComVBString = CComBSTR.

I also checked what ATL did, and it basically converted the ANSI string to Unicode with

nResult = MultiByteToWideChar(_acp_ex, 0, lp, nLen, str, nConvertedLen);

where str is of type BSTR and

str = ::SysAllocStringLen(NULL, nAllocLen);

_acp_ex is some weird stuff I don't know.

I think I found the "problem" - once I had time to play with Excel myself.

Code:

Public Declare Function lstrlenA Lib "kernel32.dll" (ByVal s As String) As Long

Function lstrlenA_wrap(s As String) As Long
    lstrlenA_wrap = lstrlenA(s)
End Function

Originally Posted by Excel 2007 Worksheet

=lstrlenA("ABC") evaluates to 1
=lstrlenA_wrap("ABC") evaluates to 3

So the lesson learned is: Calling directly from the worksheet always uses Unicode BSTR's. I haven't see that documented anywhere...

>> I got it working by passing a string to VBA via a callback function.
If it's marshaled vial COM, then BSTR's are always Unicode.

gg