unicode strings are half-implemented in the engine. There are many functions that don't work with unicode strings. error funtion is one of those, I guess. I remember str_len, str_clip and str_trunc failing too. There might be more...
Yes, I found out about that some time ago, but there were always methods to work around these problems. Anyway, as a matter of fact, it seems that file_open_write or _read belong to those commands that don't support Unicode, and there seems to be no workaround for that.
The string you retrieved is correct, however if you use it with a function that expects non-unicode strings like error() they don't work correctly. In this case the first character ('C') of your string is not one byte large as the engine expects because it's unicode (still, it happens to have the same ascii value in the first byte). (...)
Like txesmi said, TEXT and PANEL can display the string correctly. draw_text() works aswell (I believe it works the same as TEXT/PANEL drawing)
Sorry, yes, you were right. The retrieved string was indeed correct, and it's also displayed correctly when using draw_text. However, when I now use this string to create and write into a file, guess what happens.
HRESULT WINAPI SHGetFolderPath(HWND hwndOwner, int nFolder,HANDLE hToken,DWORD dwFlags,char* pszPath);
#define PRAGMA_API SHGetFolderPath;Shell32.dll!SHGetFolderPathW
char temp_getfolder[260];
STRING* str_sv_dir="";
const int APPDATA = 0x001A;
function get_appdata_folder_startup()
{
SHGetFolderPath(NULL,APPDATA,0,NULL,temp_getfolder);
STRING* wstr = str_createw(temp_getfolder);
str_cat(wstr,"\\MyGame\\test.txt");
var filehandle = file_open_write(wstr);
file_str_write(filehandle,"Look guys, we're writing into the file!");
file_close(filehandle);
// --> ...and now look for a file named 'C' in your project directory. :(
while(1)
{
draw_text(wstr,800,560,vector(100,100,255)); // yes, that's actually the correct path
wait(1);
}
}
I guess that's the proof that file_open_write does not know Unicode. What shall I do now? Is it really the only feasible option to create a DLL-plugin that works around this problem, with custom file and folder handling? It sure looks that way. Please tell me there's an easier way.
