Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 11 to 20 of 22 total |
Chinese Charatcers & DBISAM V3.3 |
Fri, Oct 6 2006 7:11 PM | Permanent Link |
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 | |
Sat, Oct 7 2006 3:26 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Just to be polite can you pick a name for yourself
Roy Lambert |
Sat, Oct 7 2006 4:01 AM | Permanent Link |
Dan Rootham | 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 |
Sat, Oct 7 2006 4:11 AM | Permanent Link |
Dan Rootham | 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 |
Sun, Oct 8 2006 5:13 AM | Permanent Link |
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 | |
Sun, Oct 8 2006 5:16 AM | Permanent Link |
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 | |
Mon, Oct 9 2006 3:30 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Trevor
Looking at the headers there is no "From" header - what this means in terms of your newsreader I have no idea. Roy Lambert |
Mon, Oct 9 2006 7:40 AM | Permanent Link |
"Trevor Keegan" | Hello Roy,
Hmmmm, I have just tried deleting the whole evelate account and recreating it.....hopefully this will solve the problem. Regards Trevor Keegan |
Mon, Oct 9 2006 9:33 AM | Permanent Link |
Dan Rootham | 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 |
Mon, Oct 9 2006 2:08 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
« Previous Page | Page 2 of 3 | Next Page » |
Jump to Page: 1 2 3 |
This web page was last updated on Sunday, May 19, 2024 at 08:46 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |