vb string to char array

[Kynrek]

i want to send a string to my vc dll from vb

when vc writes to the file the text is not the same as what was sent from vb,

basicly i want to go from a lpstr from vb to a c++ character array

void __stdcall FillString(LPSTR pszString)
{
// Create a temp buffer with our string
char buffer[256];
strcpy(buffer,pszString);


ofstream SaveFile("test.txt"

SaveFile << buffer;

SaveFile.close();


}

 

[palbano]

They hide that information in the documentation... i really wish they would stop doing that!

http://msdn.microsoft.com/library/d...98/html/vbconpassingstringstodllprocedure.asp

-pete

 

[Cagliostro]

faq207-1044

Ion Filipski

ICQ: 95034075
AIM: IonFilipski
filipski@excite.com

 

[Kynrek]

I am a vb programmer doing a quick c++ dll so i dont understand that much C++

not to be lazy, but i dont quite understand all of that documentation, i get the idea but i cant put it into code i'm confused by all the conversions,

so the string from vb is in bstring and lpstr format which
has the legnth of the string in the first 2 characters and is null terminated

and the character array dosent have either of those properties

i'm guessing my vb string is in unicode and the character array is in ascii or vice versa

could someone plase please fix my code so the LPSTR pszString is converted to a character array?

void __stdcall FillString(LPSTR pszString)
{
// Create a temp buffer with our string
char buffer[256];
strcpy(buffer,pszString);
ofstream SaveFile(&quot;test.txt&quot;

SaveFile << buffer;

SaveFile.close();

}

 

[Cagliostro]

LPSTR is quite the same thing like char* or char[]. You should convert it like is written in FAQ. There are many samples on using it. Each line in the FAQ is a sample of different kind of str <> bstr conversion.

Ion Filipski

ICQ: 95034075
AIM: IonFilipski
filipski@excite.com

 

[PerFnurt]

>so the string from vb is in bstring
Yes. A string in VB is called BSTR in VC++. The B in BSTR stands for Basic.

>could someone plase please fix my code so the LPSTR pszString is converted to a character array

But the LPSTR IS a character array!

Since your function is to be called from VB it should probably be defined as

void __stdcall FillString(BSTR s);

as BSTR is the string that VB sends to your VC++ function.

The question is the how to convert BSTR to a &quot;normal&quot; VC++ character array. As IonFilipki mention in the FAQ you can use _bstr_t for this.

Something like:

void __stdcall FillString(BSTR stringFromBasic)
{
  _bstr_t bStr(stringFromBasic);
  LPCTSTR aConstTCharArray = bStr;
  LPSTR anCharArray = bStr;
  ...
  etc

/Per
[sub]
if (typos) cout << &quot;My fingers are faster than my brain. Sorry for the typos.&quot;;
[/sub]

 

[LazyMe]

It is not necessary to deal with any conversion. Very few of the Windows APIs accept a BSTR and yet they all can be used by a VB application (and they do not use any conversion as well).

It is true that VB internally works with the BSTR type when dealing with strings. However, when using functions exported by APIs (public declare function as ... etc.) VB automatically always converts the BSTR to an ansi string, which is perfectly suitable in the c++ function to be used as a char*. This is why in VB you always have to use the &quot;A&quot; (ANSI) variant of the exported functions, instead of the &quot;W&quot; (WIDE char).

Greetings,
Rick

 

[palbano]

We have had a surge of posts from people that don't know C++ but are given production assignments to work with C++. We need to make a video; &quot;Managers gone wild&quot;

And so I wake in the morning
And I step outside
And I take a deep breath and I get real high
And I scream at the top of my lungs
What's going on?
4 non blonds

-pete

 

[Cagliostro]

>LazyMe
>....Very few of the Windows APIs accept a BSTR ....
All win32 uses inside UNICODE (ie BSTR). All things you do with ASCII is translated to UNICODE, processed, and maybe results translated from UNICODE to ASCII back, you too see them. All these things happend when you don't use UNICODE. If you use UNICODE you application will become faster and compatible with any nonenglish languages without any changes.

Ion Filipski

ICQ: 95034075
AIM: IonFilipski
filipski@excite.com

 

[LazyMe]

IonFilipsi

That totally depends on the operating system you're runnning. Only NT-based use UNICODE inside. Furthermore they do not accept, nor work with BSTR; a BSTR is not the same as an array of WCHARs. This is a very dangerous mix-up.....

Totally agree on you that you should use UNICODE when targetting such a system though. But since you can't get around the fact that VB will always translate its internal BSTRs to ansi strings when it acceses APIs (no matter what operating system you're using) and taking into account that the poster is not a C++ programmer, easiest way to work is to just not translate anything for him.

Greetings,
Rick

 

[LazyMe]

Whoops, forgot something;

This also implies that PerFnurt's post is incorrect, since the string you'll get from VB passed to your function is not a BSTR anymore, but rather a simple array of characters (NOT unicode...).

Actually this whole visual basic BSTR internal - ansi external stuff is one of the mayor drawbacks a VB programmer suffers....

Greetings,
Rick

 

[palbano]

>> All win32 uses inside UNICODE

BSTR is not == to WCHAR array. So while the point about the OS natively using WCHAR is correct, within the context of VB interfacing with C calls it is somewhat misleading.

VB programmers can not effect the way the VB library translates BSTR into LPSTR types during DLL calls. The performance hit in this case is unavoidable if you are indeed running a WCHAR OS version. It is just another sad legacy of VB.

-pete

 

[palbano]

Rick, i cross posted you [red]times two[/red]! Man you type fast

-pete

 

[PerFnurt]

>This also implies that PerFnurt's post is incorrect

No surprise. I got things mixed up. Not for the first time.


/Per
[sub]
if (typos) cout << &quot;My fingers are faster than my brain. Sorry for the typos.&quot;;
[/sub]

 

[Cagliostro]

>LazyMe
>Only NT-based use UNICODE inside
Jeffrey Richter has a manual about advansed win32 programming for proffessionals. Would be great to read it.

In C++ BSTR is defined like wchar_t*. Only difference between BSTR and unicode string, is what the first wchat_t of basic string contains the lenght of the string(only in basic). That's because a BSTR can contain any characters including \0. To create a BSTR to communicate with VB programs you should use SysAllocString instead of passing it directly. In C++ is no difference between wchar_t and BSTR.


Ion Filipski

ICQ: 95034075
AIM: IonFilipski
filipski@excite.com

 

[palbano]

No. It is just not consistent see that is the problem as related to VB. WCHAR is always WCHAR but BSTR it depends:

#if defined(WIN32) && !defined(OLE2ANSI)
typedef WCHAR OLECHAR;
#else
typedef char OLECHAR;
#endif
typedef OLECHAR* BSTR;

-pete

 

[Cagliostro]

OLE2ANSI? sounds too old for me,
something like Windows 3.11...

Ion Filipski

ICQ: 95034075
AIM: IonFilipski
filipski@excite.com

 

[Kynrek]

ok i'm getting frustrated i'm gong to be blunt

make the character array buffer and pszString equal

strcopy dosnet work the buffer has garbage in it

is it possible?

void __stdcall FillString(LPSTR pszString)
{
// Create a temp buffer with our string
char buffer[256];
strcpy(buffer,pszString);
ofstream SaveFile(&quot;test.txt&quot;

SaveFile << buffer;

SaveFile.close();

}

 

[LazyMe]

One of the reasons that you just cannot treat BSTR as WCHAR is indeed because of the fact that the BSTR might contain embedded NULLs. Furthermore a BSTR indeed is created by SysAllocString and should ALWAYS be destroyed or changed by using those API calls. And next, it is NOT tue that only VB proceeds its strings with a lengh indicator; ALL BSTRs do that, this is one of the things that makes it a BSTR....

There is a great piece of info on the Cpp forum on the MSDN site which explains exactly the differences of the two and why you should NOT treat them as being the same.

And yes, indeed... there are still systems that do NOT use UNICODE internally... and these will have to do conversion back to ansi.

Greetings,
Rick