Jump to content
  • Advertisement
Sign in to follow this  
PolyStream

Can't convert LPSTR to LPCWSTR

This topic is 4322 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, Yesterday I had a problem... thanks to you all I've resolt part of it... The texture class that I'm writing has a member LPCTSTR texfname that contains the texture filename used to load the tex in Direct3D9. I've incuded this class in a DLL and I'm using MS VisualC++ 2005 Express + Platform SDK. When you take a texture filename from a X file, you must take a D3DXMATERIAL* It contains a texturefilename, but it's LPSTR. When I pass this parameter to my LPCSTR member, I've conversion errors... I think the problem is for passing from char* to wchar_t* Sick of it... I've insert all the class file in the example application.... surprise! It works well... very well!! So the problem is that dll can't convert a LPSTR directly to LPCWSTR??????????? Please help me!!!

Share this post


Link to post
Share on other sites
Advertisement
Casting the LPSTR to an LPCWSTR should help. I'm used to converting from std::string to LPCWSTR so I'm not 100% sure.
I've also seen that putting an L before the quotes fixes it but I'm not certain that it would work in this case.

Share this post


Link to post
Share on other sites
I've try the casting... but the problem is not fixed...

If I create a LPCTSTR and initialize that in this way:
LPCTSTR file= L"texture.bmp";
all works ok!

But if I use a cast from a LPSTR I've the same problem...

Share this post


Link to post
Share on other sites
That one parameter in the D3DXMATERIAL structure makes using UNICODE with DirectX difficult. You will have to convert the wchar* string to a char* string. The WideCharToMultiByte function does this.

However, if you store it in your D3DXMATERIAL structure after conversion, will you be able to read the texture file in later? Since the UNICODE format can hold many more characters than multibyte, you would need to ensure that the file name is convertible between them.

Share this post


Link to post
Share on other sites
Hi,

You're right!!!!!

I've discovered in the project settings that I'm using Unicode... so I swap sooner to MultyByte... and now it works fine!!!

Thanks a lot I've pass a day on gdnet and google to find a solution to fix my bugs... and.... It was only a wrong setting ^_^


Thanks a lot to you all!!!!

Share this post


Link to post
Share on other sites
The quick and dirty solution that works for me is to cast the Wide char sring to and array shorts. As long as your string is actually ASCII each short will be in the form 0x0X where x is the 8-bit ASCII code for the character.

Share this post


Link to post
Share on other sites
Quote:
Original post by griffin2000
The quick and dirty solution that works for me is to cast the Wide char sring to and array shorts. As long as your string is actually ASCII each short will be in the form 0x0X where x is the 8-bit ASCII code for the character.


If your intent is to put the file name in the material to ultimately save it to a .x file (why else would you save it there?), you can't do that. When DX is writing the file name to the file, it will try to find the length, and if it is really a UNICODE string it will stop at the first NULL byte.

Share this post


Link to post
Share on other sites
For people who are using unicode:


LPCWSTR MultiCharToUniChar(char* mbString)
{
int len = 0;
len = (int)strlen(mbString) + 1;
wchar_t *ucString = new wchar_t[len];
mbstowcs(ucString, mbString, len);
return (LPCWSTR)ucString;
}


Share this post


Link to post
Share on other sites
I'm sure MauraderX's code will work, but it is generally not a good idea to return dynamically allocated data from a function since the caller then has to remember to free it.

Unless the function is externally documented, the caller cannot know whether the data was allocated with new or with malloc, so can't guarantee releasing the buffer correctly.

And if the function was to sit in a DLL, there is no real way to free it at all.

It would probably be better to have the caller pass in the output buffer along with a maximum length, since they are also then responsible for allocating the buffer and are less likely to forget to free it, or attempt to free it incorrectly.

Minor point really.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!