Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 8 of 8 total |
Unicode in Delphi XE |
Thu, Apr 24 2014 5:44 AM | Permanent Link |
David | Hi all, just looking for a bit of advice. I have an app developed in Delphi 2006 with IW 9 and DBISam v4 and I am looking to migrate these to Delphi XE and IW 14.
I am aware of the option to change all strings to AnsiString but I was wondering is this really needed providing all the strings only contain ANSI characters in the first place? I would really appreciate any advice on this, and also, are there any other issues to watch out for when changing over to a Unicode version of Delphi. I don't do anything fancy with pointers or the like, just basic string operation like copy, length, pos etc. Is there a way to prevent a user from entering in Unicode into edit boxes etc? I know that they will accept this input, but when it is saved to DBISam it will not be able to handle this character and it will be converted to a question mark, so better to prevent this in the first place. I am intending to move over to ElevateDB but that will be a longer term plan and I need to support my existing application with DBISam for some time yet. Thanks David. |
Thu, Apr 24 2014 9:17 AM | Permanent Link |
Matthew Jones | I'd say "just do it". I did and it hasn't been an issue. The strings are only a
problem if you are sending them over boundaries, as the conversions seem to be just fine. If need be, convert them to UTF8String first, and then they squeeze into AnsiStrings without bother. I guess what I'm saying is that this is generally not any sort of an issue in general, but there are solutions if you come across something. /Matthew Jones/ |
Fri, Apr 25 2014 5:42 AM | Permanent Link |
David | Thanks Mathew, good to know your experience as well. So far everything does seem fine which is good.
I will probably develop a routine to detect Unicode so I can prevent the user from trying to enter those characters as they just get converted to question marks anyway and I would like to prevent it. I did develop something that kind of works but not completely. Cheers for your reply. David (Matthew Jones) wrote: I'd say "just do it". I did and it hasn't been an issue. The strings are only a problem if you are sending them over boundaries, as the conversions seem to be just fine. If need be, convert them to UTF8String first, and then they squeeze into AnsiStrings without bother. I guess what I'm saying is that this is generally not any sort of an issue in general, but there are solutions if you come across something. /Matthew Jones/ |
Mon, Apr 28 2014 11:14 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | David,
<< I am aware of the option to change all strings to AnsiString but I was wondering is this really needed providing all the strings only contain ANSI characters in the first place? >> I wouldn't worry about it. Unless the user is inputting characters for a non-Western language that requires multi-byte character sequences, you will be fine just leaving things as-is and allowing Delphi XE to perform the implicit conversions. Tim Young Elevate Software www.elevatesoft.com |
Thu, May 1 2014 5:22 AM | Permanent Link |
David | Hi Tim.
Thanks for that, I probably will do that but I would have liked to prevent any Unicode characters being entered in the first place. I have not managed to get that to work though. Do you know of any way to tell if a character is not in the current code page? that would then allow me to inform the user of an invalid character being entered, rather than it just appearing as a random '?' character. I can't simply check for Question marks as they might actually be valid input. "Tim Young [Elevate Software]" wrote: David, << I am aware of the option to change all strings to AnsiString but I was wondering is this really needed providing all the strings only contain ANSI characters in the first place? >> I wouldn't worry about it. Unless the user is inputting characters for a non-Western language that requires multi-byte character sequences, you will be fine just leaving things as-is and allowing Delphi XE to perform the implicit conversions. Tim Young Elevate Software www.elevatesoft.com |
Thu, May 1 2014 7:32 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | David
You can either add an event handler (OnKeyDown I think is the best one) for the input control and check that the character is one you're happy with if not set to 0 or subclass the input control to achieve the same result. I'd go for subclassing myself since that's a lot easier than adding events to loads of controls CAVEAT: I'm still using D2006 so could be totally wrong. Roy Lambert |
Thu, May 1 2014 9:41 AM | Permanent Link |
David | Hi Roy.
The input checking is for an IW application though, so no KeyDown events. What I am finding is if I convert a Unicode string to an AnsiString any invalid characters get changed to a '?' What I would like is the ability to check to see if that character conversion failed. Roy Lambert wrote: David You can either add an event handler (OnKeyDown I think is the best one) for the input control and check that the character is one you're happy with if not set to 0 or subclass the input control to achieve the same result. I'd go for subclassing myself since that's a lot easier than adding events to loads of controls CAVEAT: I'm still using D2006 so could be totally wrong. Roy Lambert |
Thu, May 1 2014 10:59 AM | Permanent Link |
Malcolm Taylor | David
Have you considered transliteration? If your application only encounters a small range of known 'languages' you may be able to transliterate to a particular Ansi code page. You can Google for transliteration tables as well as code examples in a few languages. Most of mine is done on the web using PHP. I have a worse problem of having to convert many European characters to ASCII. Using transliteration I convert from a bunch of languages such as Russian, Greek, Polish, Lithuanian, German etc, to ASCII. It is not perfect, but it guarantees valid, and usually comprehensible, results - much better than a string of ????s. Malcolm |
This web page was last updated on Saturday, May 4, 2024 at 12:54 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |