471,084 Members | 1,042 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,084 software developers and data experts.

LPCSTR from String

Hi,

I am using VS 2003 writing a managed C++ windows app.
I am calling PlaySound. The first parameter is a LPCSTR. I have a String
*str representing a filename. I like using the String class because the file
name needs to be built on the fly.
How do I get from String * I have to the LPCSTR it wants? I have searched
around for this and it seems to be a common question but I can not find a
simple answer.

Thank you,
Joe
Nov 17 '05 #1
13 5705
This seems to be the easiest way that I have found. First have a buffer
large enough or dynamically allocate one based on yourString->Length.

char buffer[512];
sprintf(buffer, "%s", yourString);

mosimu

"Joe Thompson" wrote:
Hi,

I am using VS 2003 writing a managed C++ windows app.
I am calling PlaySound. The first parameter is a LPCSTR. I have a String
*str representing a filename. I like using the String class because the file
name needs to be built on the fly.
How do I get from String * I have to the LPCSTR it wants? I have searched
around for this and it seems to be a common question but I can not find a
simple answer.

Thank you,
Joe

Nov 17 '05 #2
"Joe Thompson" <Jo*********@discussions.microsoft.com> wrote in message
news:D1**********************************@microsof t.com...
I am using VS 2003 writing a managed C++ windows app.
I am calling PlaySound. The first parameter is a LPCSTR. I have a String
*str representing a filename. I like using the String class because the
file
name needs to be built on the fly.
How do I get from String * I have to the LPCSTR it wants?


I'm not sure if your question has to do with ANSI/UNICODE or
managed/unmanaged issues.

To set the stage:

PlaySound is actually a macro that equates to PlaySoundA in ANSI builds and
PlaySoundW in UNICODE builds.

An LPCSTR is a pointer to an ANSI string.

..Net strings are composed of UNICODE characters.

That said, this works by pinning the string (prevent it from being moved by
the GC), getting a pointer to the first character of the string, and passing
off the pointer to a native function:

#include <vcclr.h>

System::String *str = new System::String("C:\\windows\\media\\windows xp
startup.wav");
wchar_t __pin *p = PtrToStringChars(str);

PlaySoundW(p, 0, SND_FILENAME | SND_SYNC);

Regards,
Will

Nov 17 '05 #3
Hi =?Utf-8?B?Sm9lIFRob21wc29u?=,
I am using VS 2003 writing a managed C++ windows app.
I am calling PlaySound. The first parameter is a LPCSTR. I have a
String *str representing a filename. I like using the String class
because the file name needs to be built on the fly.
How do I get from String * I have to the LPCSTR it wants? I have
searched around for this and it seems to be a common question but I
can not find a simple answer.


See: How To Convert from System::String* to Char* in Visual C++ .NET
http://support.microsoft.com/kb/311259/

For TCHAR support see: Convert from System::String* to TCHAR*/CString
http://blog.kalmbachnet.de/?postid=18

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
Nov 17 '05 #4
I thinnk this has more importance as a managed/unmanaged issue. I don't know
much about LPCSTR, but belive this can hold pointer to both ANSI and UNICODE
string. Up from NT5 windows uses unicode, can some one explane on these
context

"William DePalo [MVP VC++]" wrote:
"Joe Thompson" <Jo*********@discussions.microsoft.com> wrote in message
news:D1**********************************@microsof t.com...
I am using VS 2003 writing a managed C++ windows app.
I am calling PlaySound. The first parameter is a LPCSTR. I have a String
*str representing a filename. I like using the String class because the
file
name needs to be built on the fly.
How do I get from String * I have to the LPCSTR it wants?


I'm not sure if your question has to do with ANSI/UNICODE or
managed/unmanaged issues.

To set the stage:

PlaySound is actually a macro that equates to PlaySoundA in ANSI builds and
PlaySoundW in UNICODE builds.

An LPCSTR is a pointer to an ANSI string.

..Net strings are composed of UNICODE characters.

That said, this works by pinning the string (prevent it from being moved by
the GC), getting a pointer to the first character of the string, and passing
off the pointer to a native function:

#include <vcclr.h>

System::String *str = new System::String("C:\\windows\\media\\windows xp
startup.wav");
wchar_t __pin *p = PtrToStringChars(str);

PlaySoundW(p, 0, SND_FILENAME | SND_SYNC);

Regards,
Will

Nov 17 '05 #5
Hi =?Utf-8?B?Qmlqb3k=?=,
I don't know much about LPCSTR, but belive this can hold pointer
to both ANSI and UNICODE string.
No, LPCSTR only handles ANSI (or MBCS) strings (char*)

To support bith you should use LPCTSTR.
Up from NT5 windows uses unicode, can some
one explane on these context

???

Starting with NT (3.01) it uses unicode as fundamental string encoding!

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
Nov 17 '05 #6
Hi mosimu,

This seems to work fine.

Thanks for the help,
Joe

"mosimu" wrote:
This seems to be the easiest way that I have found. First have a buffer
large enough or dynamically allocate one based on yourString->Length.

char buffer[512];
sprintf(buffer, "%s", yourString);

mosimu

"Joe Thompson" wrote:
Hi,

I am using VS 2003 writing a managed C++ windows app.
I am calling PlaySound. The first parameter is a LPCSTR. I have a String
*str representing a filename. I like using the String class because the file
name needs to be built on the fly.
How do I get from String * I have to the LPCSTR it wants? I have searched
around for this and it seems to be a common question but I can not find a
simple answer.

Thank you,
Joe

Nov 17 '05 #7
Hi William,

Your approach worked also. I am using ANSI builds though. Unless I
explicitly call PlaySoundW I get a compiler error:

error C2664: 'PlaySoundA': cannot convert parameter 1 from 'wchar_t __pin
*volitile ' to 'LPCSTR'

I think I'll use mosimu's approach for now, it seems simpler.

Thank you for the help,
Joe

"William DePalo [MVP VC++]" wrote:
"Joe Thompson" <Jo*********@discussions.microsoft.com> wrote in message
news:D1**********************************@microsof t.com...
I am using VS 2003 writing a managed C++ windows app.
I am calling PlaySound. The first parameter is a LPCSTR. I have a String
*str representing a filename. I like using the String class because the
file
name needs to be built on the fly.
How do I get from String * I have to the LPCSTR it wants?


I'm not sure if your question has to do with ANSI/UNICODE or
managed/unmanaged issues.

To set the stage:

PlaySound is actually a macro that equates to PlaySoundA in ANSI builds and
PlaySoundW in UNICODE builds.

An LPCSTR is a pointer to an ANSI string.

..Net strings are composed of UNICODE characters.

That said, this works by pinning the string (prevent it from being moved by
the GC), getting a pointer to the first character of the string, and passing
off the pointer to a native function:

#include <vcclr.h>

System::String *str = new System::String("C:\\windows\\media\\windows xp
startup.wav");
wchar_t __pin *p = PtrToStringChars(str);

PlaySoundW(p, 0, SND_FILENAME | SND_SYNC);

Regards,
Will

Nov 17 '05 #8
Joe Thompson wrote:
Hi William,

Your approach worked also. I am using ANSI builds though. Unless I
explicitly call PlaySoundW I get a compiler error:

error C2664: 'PlaySoundA': cannot convert parameter 1 from 'wchar_t
__pin
*volitile ' to 'LPCSTR'
Yes, that's why Wiliam explicitly used PlaySoundW in his example.

I think I'll use mosimu's approach for now, it seems simpler.


It may seem so, but it's not really the best choice:

- It's susceptible to buffer overrun errors (at least use _snprintf).
- It incurs the overhead of converting from Unicode to ANSI (in the implicit
conversion that occurs before sprintf is called).
- It probably incurs the overhead of converting from ANSI to Unicode since
most likely PlaySoundA internally converts it's arguments to Unicode and
then call PlaySoundW.
- It's less efficient.

Personally, I'd go with William's suggestion.

-cd
Nov 17 '05 #9
"Joe Thompson" <Jo*********@discussions.microsoft.com> wrote in message
news:BD**********************************@microsof t.com...
Your approach worked also.
That's good. I try hard not to give bogus answers to questions posted here.
:-)
I am using ANSI builds though. Unless I
explicitly call PlaySoundW I get a compiler error:


Right.

That's to be expected. Dot Net strings are composed of 16 bit characters.
PlaySoundA() which is what you are calling takes 8 bit characters,
PlaySoundW() 16. There is no actual PlaySound() - merely a macro that is
defined to be one or the other of the A and W variants.

Note that NT operating systems (NT/2K/XP/2K+3) all use 16 bit characters
internally. So, almost any time a string is passed to an o/s exported API,
it is widened to 16 bit characters in the in the A version. And almost all
o/s exported APIs returning strings return them as strings of 16 bit
characters. So the A version of such a function has to "narrow" them on
return.

Regards,
Will
Nov 17 '05 #10
Thanks for the clarification. After reading this and Carl's response, I
guess this approach is better...

Joe

"William DePalo [MVP VC++]" wrote:
"Joe Thompson" <Jo*********@discussions.microsoft.com> wrote in message
news:BD**********************************@microsof t.com...
Your approach worked also.


That's good. I try hard not to give bogus answers to questions posted here.
:-)
I am using ANSI builds though. Unless I
explicitly call PlaySoundW I get a compiler error:


Right.

That's to be expected. Dot Net strings are composed of 16 bit characters.
PlaySoundA() which is what you are calling takes 8 bit characters,
PlaySoundW() 16. There is no actual PlaySound() - merely a macro that is
defined to be one or the other of the A and W variants.

Note that NT operating systems (NT/2K/XP/2K+3) all use 16 bit characters
internally. So, almost any time a string is passed to an o/s exported API,
it is widened to 16 bit characters in the in the A version. And almost all
o/s exported APIs returning strings return them as strings of 16 bit
characters. So the A version of such a function has to "narrow" them on
return.

Regards,
Will

Nov 17 '05 #11
m> This seems to be the easiest way that I have found. First have a
m> buffer large enough or dynamically allocate one based on
m> yourString->Length.
m>
m> char buffer[512]; sprintf(buffer, "%s", yourString);

First, you should use StringCchPrintf instead of sprtinf to avoid buffer
overflow.

Second, the code above is just equal to writing (LPCTSTR)yourString, so why
use it?!

--
Serge

Nov 17 '05 #12
Hi William DePalo [MVP VC++],
PlaySoundA() which is what you are calling takes 8 bit
characters, PlaySoundW() 16. There is no actual PlaySound() - merely a
macro that is defined to be one or the other of the A and W variants.


Just a small note: Win9x/Me does not support 16-bit chars by default.
And therefor will not work with PlaySoundW.

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
Nov 17 '05 #13
"Jochen Kalmbach" <no********************@holzma.de> wrote in message
news:Xn*********************************@127.0.0.1 ...
Just a small note: Win9x/Me does not support 16-bit chars by default.
And therefor will not work with PlaySoundW.


Absolutely true, which is whay I wrote in the next paragraph after the line
you quoted: "Note that NT operating systems (NT/2K/XP/2K+3) all use 16 bit
characters
internally." For the sake of completeness, 9x doesn't support PlaySoundW()
by default, but it does in the presence of MSLU.

Regards,
Will
Nov 17 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

16 posts views Thread by Krakatioison | last post: by
5 posts views Thread by Stu Cazzo | last post: by
2 posts views Thread by Bragadiru | last post: by
3 posts views Thread by George Ter-Saakov | last post: by
6 posts views Thread by John Lucas | last post: by
2 posts views Thread by Neo | last post: by
7 posts views Thread by Toni | last post: by
1 post views Thread by vb739 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.