On Tue, 06 Oct 2009, Szak�ts Viktor wrote:
> I've recently enabled UNICODE for all non-x86 win builds
> exactly for above reason.

Thank you very much and also for your tests.

> Oh I see. I was missing hb_setTermCP() in Windows builds.
> Adding it fixed GTWVT UNICODE build. (I didn't retest non-UNICODE
> yet, I hope it stays OK too)

In non unicode builds it can be used only for character translations
but it cannot change font encoding. It can be done only using MS CP
number with HB_GTI_CODEPAGE though if someone has a while then he
can create function which will translate our unicode CPs to MS CP
numbers and we can use it inside SETDISPCP() method to automatically
set font encoding in non unicode GTWIN and GTWVT builds.

> With GTWIN the remaining problems are HB_GTI_WINTITLE
> CP in UNICODE mode (I didn't report this before), plus the

I guess you are talking about national characters but it's
general problem which should be covered globally for all
windows Unicode translation inside common/hbwince.c which
should respect HVM CP.
As temporary workaround you can add additional translation
using _SET_OSCODEPAGE so it will work like for file names.

> high level drawing (seemingly window related) problem. I'll
> try to make tests with 32-bit UNICODE to check what exactly
> enables this.

AFAIK Windows does not use 32-bit UNICODE values and support only U16.
What is the exact problem?
If you are talking about save/restore which drops box characters
then you should disable VGA compatible video buffer and enable
extended attributes in {Save,Rest}Screen() data by:

   hb_gtInfo( HB_GTI_COMPATBUFFER, .F. )

best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to