Unicode support arrives (in SVN)

BlitzMax Forums/BlitzMax Programming/Unicode support arrives (in SVN)

Brucey

(Posted 2009) [#1]

The SVN version of Blitzmax now supports Unicode filesystems.

If you have problems, remembering that SVN is "in development", then feel free to shoot the messenger, as it is all my fault.

I'm 99% sure I've covered everything, but you know how it goes... so if stuff stops working, you should be vocal about it. (although verbal abuse should remain at your end of the keyboard) :-)

BlitzMax compiling is NOT Unicode friendly yet. So if you try to build something in a non-ASCII folder, don't expect to get very far ;-)
Hopefully, it'll all filter down into the toolset over time.

For pre Win2k/NT systems, you may need to include Unicows, but Seb knows more about that than me, so I think he should explain what that's all about. (Go Seb!)

Otherwise, everything should work as it did before. ie. you shouldn't notice any difference. Obviously if your app doesn't work at all now, then there's a bug somewhere :-)

Enjoy

:o)

xlsior

(Posted 2009) [#2]

Nice!

I think it's time they issue you one of these:

xlsior

(Posted 2009) [#3]

EDIT: Hmmmm... some problems with the new version.

The Threading version of MaxGUI fails now building with the following error:

c:/code/blitzmax/mod/maxgui.mod/win32maxgui.mod/win32gui/win32button.cpp: In constructor `Win32Button::Win32Button(BBGroup*, int)':
c:/code/blitzmax/mod/maxgui.mod/win32maxgui.mod/win32gui/win32button.cpp:21: error: cannot convert `const wchar_t*' to `const CHAR*' for argument `2' to `HWND__* CreateWindowExA(DWORD, const CHAR*, const CHAR*, DWORD, int, int, int, int, HWND__*, HMENU__*, HINSTANCE__*, void*)'

Build Error: failed to compile c:/code/blitzmax/mod/maxgui.mod/win32maxgui.mod/win32gui/win32button.cpp

I wiped the MaxGUI folder and re-downloaded it, but the build still fails with the same error. Any ideas? :-?

Brucey

(Posted 2009) [#4]

Any ideas?

in brl.mod/blitz.mod/blitz.h

try adding :

#define UNICODE

before this

#ifdef THREADED
#include "bdwgc/include/gc.h"
#endif

And let me know if that solves it.

xlsior

(Posted 2009) [#5]

Yup, that appears to have fixed it, with that addition it compiled without errors.

Thanks again!

Jim Teeuwen

(Posted 2009) [#6]

You sir, are my hero.

siread

(Posted 2009) [#7]

markcw

(Posted 2009) [#8]

Hold on, Brucey can't be *both* Superman and Batman, that's just silly.

Brucey

(Posted 2009) [#9]

...and anyways... I don't really have time to be saving the world. Got modules to work on!! :-p

Retimer

(Posted 2009) [#10]

Hold on, Brucey can't be *both* Superman and Batman, that's just silly.

It's surprising what brucey can pull off =p

Kurator

(Posted 2009) [#11]

hi,

unfortunately i got the same error, but bruceys solution did not fix the problem, bmk throws again the error

any suggestions?

Brucey

(Posted 2009) [#12]

It should solve the issue. Otherwise you must have a different error?

Kurator

(Posted 2009) [#13]

D:/BlitzMaxSNV/dev/main/mod/maxgui.mod/win32maxgui.mod/win32gui/win32button.cpp:
In constructor `Win32Button::Win32Button(BBGroup*, int)':
D:/BlitzMaxSNV/dev/main/mod/maxgui.mod/win32maxgui.mod/win32gui/win32button.cpp:
21: error: cannot convert `const char*' to `const WCHAR*' for argument `2' to `H
WND__* CreateWindowExW(DWORD, const WCHAR*, const WCHAR*, DWORD, int, int, int,
int, HWND__*, HMENU__*, HINSTANCE__*, void*)'
Build Error: failed to compile D:/BlitzMaxSNV/dev/main/mod/maxgui.mod/win32maxgu
i.mod/win32gui/win32button.cpp
D:\BlitzMaxSNV\dev\main\bin>

it happens both on building threaded or non threaded

This ist beginning of my modified blitz.h

#ifndef BLITZ_H
#define BLITZ_H


#include <pub.mod/stdc.mod/stdc.h>

#define UNICODE
#ifdef THREADED
#include "bdwgc/include/gc.h"
#endif

MinGW Version

D:\BlitzMaxSNV\dev\main\bin>gcc --version
gcc (GCC) 3.4.5 (mingw-vista special r3)

Brucey

(Posted 2009) [#14]

Have you sync'd your MaxGUI with the latest in SVN?

Kurator

(Posted 2009) [#15]

oh, many thanks for the tipp - it is in the same dir, but has to be updated seperately

after syncing it worked flawlessy :)

SebHoll

(Posted 2009) [#16]

Hi Brucey,

Just noticed that, after a "Rebuild All Modules" on Windows, MaxIDE now chokes at start-up complaining about not being able to find the BlitzMax version which means that CreateProcess() is failing to start the 'bcc' process.

Looks like Pub.FreeProcess perhaps needs some Brucey-love. Replacing the fdProcess declaration in freeprocess.bmx with...

?Win32
Function fdProcess(exe$w,in_fd Ptr,out_fd Ptr,err_fd Ptr,flags)="fdProcess"
?Not Win32
Function fdProcess(exe$z,in_fd Ptr,out_fd Ptr,err_fd Ptr,flags)="fdProcess"
?

...seems to fix this particular case, but the fdRead() and fdWrite() stuff probably needs some attention and the *nix declarations probably want UTF8'ing. ;-)

Any thoughts?

Brucey

(Posted 2009) [#17]

ahh... it's complicated..

ReadFile() - which is used internally, will be working on wchar_t, I guess... which complicates things somewhat probably.

Since Skid is the mastermind behind this, perhaps he has an idea of the best way to handle this.

I wouldn't want the API to be different (ie. Short Ptr instead of Byte Ptr) for Read() or Write().
Perhaps internally it wants to use a wchar_t buffer and copy the byte data???

Brucey

(Posted 2009) [#18]

Unless we don't care what the bytes are - since it may well be binary data... and you don't want to mess with it.
Leave it up to the user to worry about the data stream?

fdProcess of course needs the fix.

Brucey

(Posted 2009) [#19]

After further review, I think we can get away with not changing fdread and fdwrite... (heh.. at least until it doesn't work!) :-p