Passing arguments from VBA to DLL

Now you mention that, changing the declare of lstrlenA to the Wide version;
Public Declare Function lstrlenW Lib "kernel32" (ByVal lpString As String)
As Long

now works fine the worksheet also.

IIRC normally when calling window function from VB there is Unicode > ANSI
conversion. Hence the "A" versions of these function are used.
If I wanted to use the W version it would be
Public Declare Function lstrlenW Lib "kernel32" (ByVal lpString As Long) As
Long
and call it with
lstrlenW(strPtr("MyString"))

From the worksheet, seems the conversion does not occur.

NickHK


<mkluwe@gmail.com>
???????:1155826189.336921.303220@m79g2000cwm.googlegroups.com...
> mkluwe@gmail.com schrieb:
>> I just took the first few steps in writing a little DLL that should
>> be called from Excel/VBA, and I stumbled upon some wierd behaviour.
>>
>> The function in my DLL is declared as
>>
>> int __stdcall foo( const char *t );
>>
>> and is used in VBA via
>>
>> Declare Function foo Lib "C:\foo\foo.dll" (ByVal t As String) As Long
>>
>> I noticed that foo didn't work internally as I expected and added
>> writing *t to a file on each call of foo as a debugging measure.
>> According to this output, only the first character of String t seems
>> to be passed to foo when called directly from Excel (putting
>> =foo("xyz") in a cell).
>
> Let me answer my own post:
>
> Excel passes the string as some kind of wide-character. Using
> const wchar_t *t in my function works perfectly.
>
> Regards,
> Matthias
>

Hi!

NickHK schrieb:
> <mkluwe@gmail.com>
> ???????:1155826189.336921.303220@m79g2000cwm.googlegroups.com...
> > mkluwe@gmail.com schrieb:
> >> I just took the first few steps in writing a little DLL that should
> >> be called from Excel/VBA, and I stumbled upon some wierd behaviour.
> >>
> >> The function in my DLL is declared as
> >>
> >> int __stdcall foo( const char *t );
> >>
> >> and is used in VBA via
> >>
> >> Declare Function foo Lib "C:\foo\foo.dll" (ByVal t As String) As Long
> >>
> >> I noticed that foo didn't work internally as I expected and added
> >> writing *t to a file on each call of foo as a debugging measure.
> >> According to this output, only the first character of String t seems
> >> to be passed to foo when called directly from Excel (putting
> >> =foo("xyz") in a cell).
> >
> > Let me answer my own post:
> >
> > Excel passes the string as some kind of wide-character. Using
> > const wchar_t *t in my function works perfectly.

> Now you mention that, changing the declare of lstrlenA to the Wide version;
> Public Declare Function lstrlenW Lib "kernel32" (ByVal lpString As String)
> As Long
>
> now works fine the worksheet also.
>
> IIRC normally when calling window function from VB there is Unicode > ANSI
> conversion. Hence the "A" versions of these function are used.
> If I wanted to use the W version it would be
> Public Declare Function lstrlenW Lib "kernel32" (ByVal lpString As Long) As
> Long
> and call it with
> lstrlenW(strPtr("MyString"))
>
> From the worksheet, seems the conversion does not occur.

Indeed. I just found the following document:
http://msdn.microsoft.com/library/de...ce03082001.asp

It says: "Although VBA uses Unicode internally, it converts all strings
to ANSI strings before calling a function in a DLL". Thus, both Excel
and VBA use Unicode internally, but only VBA insists on conversion.

Sad situation -- I still have no better option than wrapping functions
in VBA, otherwise my DLL would have to provide two different functions
for each operation.

Regards,
Matthias

<mkluwe@gmail.com> wrote in message
news:1155884374.657132.31280@m73g2000cwd.googlegroups.com...
> Hi!
>
> NickHK schrieb:
> > <mkluwe@gmail.com>
> > ???????:1155826189.336921.303220@m79g2000cwm.googlegroups.com...
> > > mkluwe@gmail.com schrieb:
> > >> I just took the first few steps in writing a little DLL that should
> > >> be called from Excel/VBA, and I stumbled upon some wierd behaviour.
> > >>
> > >> The function in my DLL is declared as
> > >>
> > >> int __stdcall foo( const char *t );
> > >>
> > >> and is used in VBA via
> > >>
> > >> Declare Function foo Lib "C:\foo\foo.dll" (ByVal t As String) As Long
> > >>
> > >> I noticed that foo didn't work internally as I expected and added
> > >> writing *t to a file on each call of foo as a debugging measure.
> > >> According to this output, only the first character of String t seems
> > >> to be passed to foo when called directly from Excel (putting
> > >> =foo("xyz") in a cell).
> > >
> > > Let me answer my own post:
> > >
> > > Excel passes the string as some kind of wide-character. Using
> > > const wchar_t *t in my function works perfectly.
>
> > Now you mention that, changing the declare of lstrlenA to the Wide
version;
> > Public Declare Function lstrlenW Lib "kernel32" (ByVal lpString As
String)
> > As Long
> >
> > now works fine the worksheet also.
> >
> > IIRC normally when calling window function from VB there is Unicode >
ANSI
> > conversion. Hence the "A" versions of these function are used.
> > If I wanted to use the W version it would be
> > Public Declare Function lstrlenW Lib "kernel32" (ByVal lpString As Long)
As
> > Long
> > and call it with
> > lstrlenW(strPtr("MyString"))
> >
> > From the worksheet, seems the conversion does not occur.
>
> Indeed. I just found the following document:
>
http://msdn.microsoft.com/library/de...ce03082001.asp
>
> It says: "Although VBA uses Unicode internally, it converts all strings
> to ANSI strings before calling a function in a DLL". Thus, both Excel
> and VBA use Unicode internally, but only VBA insists on conversion.
>
> Sad situation -- I still have no better option than wrapping functions
> in VBA, otherwise my DLL would have to provide two different functions
> for each operation.
>
> Regards,
> Matthias

Yes, given that one converts and other does not, it would be better to
expose your function as wrapper to the private Declares. Otherwise, you will
have to rely on the user knowing to call the W version from the worksheet
and the A version from VBA.

NickHK