Can't convert LPSTR to LPCWSTR
Author
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!!!
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.
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.
Author
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...
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...
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.
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.
Author
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!!!!
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!!!!
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.
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.
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;}
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
