Hello Tim,

> Dan is correct, is you're using WideStrings then you may have an issue
> since there may be issues with converting back and forth from WideStrings
> to AnsiStrings.  DBISAM only supports AnsiStrings, which means that you
> must use AnsiStrings with multi-byte character encoding for Chinese,
> Japanese, and other languages that require large character sets (> 256
> chars).

So the real issue here as I understand it to converting between the
WideString and Anstring is the termination...or is there more to it than
that?

Regards
Trevor Keegan

Just to be polite can you pick a name for yourself

Roy Lambert

Trevor,

<< I suspect that we are using the WideStrings because there is a UniCode
property that we need to turn on in the control for each style that want to
define.  The Style then also allows us to define the CodePage and the font
styles.  Does this mean though, that if I am using WideString, that there is
no need to use the CodePage?? >>

Exactly so. The rule is to use EITHER Unicode OR a codepage setting.
Traditionally everyone used the codepage for their local language, but
Unicode allows the use of several different alphabets on a single screen.

If you are migrating data from a BDE Paradox table I would be surprised
if that data is already in Unicode format. More likely it uses a codepage.

<<.....but this would then mean that if I would have to know
in advance what type of language was going to be used.
In my case I want to allow many....here in Malaysia we use English
characters, Chinese and Tamil....just as a start.....and we have some people
here who may want to use all 3 lanuages in 1. >>

And that is where Unicode comes in. It really is the only tidy way in which
you can switch from one language to another within a single application.
And it's the only way to show multiple alphabets in one document.
That's why we didn't even go the codepage route: straight to Unicode for our
first Chinese, Japanese and Russian database application.

<<RichEdit control...>>
The problem is that Borland just gave up on implementing WideString controls
until they were forced into it for the .Net versions of Delphi. So for Unicode on
Win32 Delphi apps, you can't use standard Delphi label, edit and memo controls.
You have to install a full third-party set of controls which is widestring-aware.
There are two choices:

www.tntware.com/delphicontrols/unicode
  The TNT Unicode controls are excellent freeware and very reliable, but
  they don't do Unicode on Win9x - only on Win NT, 2000 etc.

www.lmd.de/products/lmdelpack/
  The ElPack Unicode controls from LMD are chargeable, but they do provide
  Unicode even on a Win9x platform.

Both suppliers have a support newsgroup which you can use to get started.

HTH,
Dan

Lexicon Software, Bath, UK

Trevor,

<< So the real issue here as I understand it to converting between the
WideString and Anstring is the termination...or is there more to it than
that? >>

The software needs to know which codepage to use when converting AnsiStrings
from and to Unicode. Unicode always uses 2 bytes per character (at least until
you get beyond the BMP basic multilingual plane). A codepage for Chinese will use
a variable number of bytes per character.

There is a conversion library call DIConverters on the Delphi Inspiration website:
 www.yunqa.de/delphi/converters/index.htm

Regards,
Dan

Lexicon Software Ltd, Bath, UK

Hello Dan,

Thanks...you are being very helpful

> The software needs to know which codepage to use when converting
> AnsiStrings
> from and to Unicode. Unicode always uses 2 bytes per character (at least
> until
> you get beyond the BMP basic multilingual plane). A codepage for Chinese
> will use
> a variable number of bytes per character.
Does this mean that it is not really sufficient to say that you are using
UniCode characters....that you also need to indicate which CharSet that you
are using so that the translation can be done correctly?  If this is the
case this would mean that it is not possible to mix some types of languages
even using unicode.....but this does not seem sensible.....do you know how
this works?

I am trying to get some information from the TRichView people, but by
everything that I have read, they are using UniCode...so this may explain
why I can get it to work with a Binary Field.....rather than just a straight
string Memo field.

Regards
Trevor Keegan

Hi Roy,

Yes...now that you mention it, I did see this the other day, but I did not
really think too much about it.  It is a little weird though, because when I
post on other New Groups my name appear.  To be honest I am not sure what to
look for....any pointers?

If I cannot figure it out....maybe you can just think of me an enigma

Regards
Trevor Keegan

Trevor

Looking at the headers there is no "From" header - what this means in terms of your newsreader I have no idea.

Roy Lambert

Hello Roy,

Hmmmm, I have just tried deleting the whole evelate account and recreating
it.....hopefully this will solve the problem.

Regards
Trevor Keegan

Trevor,

<< Does this mean that it is not really sufficient to say that you are using
UniCode characters....that you also need to indicate which CharSet that you
are using so that the translation can be done correctly?  If this is the
case this would mean that it is not possible to mix some types of languages
even using unicode.....but this does not seem sensible.....do you know how
this works? >>

Once your data is in WideString format, it *is* Unicode for most purposes.
And a Unicode font will represent all the required characters without you
having to specify a CharSet. It's only when you want to convert between
codepages and Unicode that  you must tell the software how to convert.

So if you need to offer several languages or several alphabets within one
application, my firm advice is to use only Unicode, not a Chinese codepage.
Keep your data in WideString format, and install third-party controls which
support Unicode. TRichEdit may be such a control (I don't know), but certainly
the other controls (TNT or ElPack) will do the job well.

Final advice: grab ElevateDB when it is released, because it will handle Unicode
much more elegantly than DBISAM.

HTH,
Dan

Lexicon Software Ltd, Bath, UK

Trevor,

<< So the real issue here as I understand it to converting between the
WideString and Anstring is the termination...or is there more to it than
that? >>

There shouldn't be an issue with the NULL termination, no.  More than likely
the issue is simply with the conversion between WideStrings and AnsiStrings,
i.e. the conversion is not occurring properly.   Are the regional settings
on the machine being used set to Chinese so that Windows knows how the
conversion from Unicode should occur ?

--
Tim Young
Elevate Software
www.elevatesoft.com