<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