On Mon, 24 Apr 2006 09:07:55 +0200
Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> Mattias Gaertner wrote:
> > On Sun, 23 Apr 2006 23:10:58 +0330
> > "roozbeh gholizadeh" <[EMAIL PROTECTED]> wrote:
> >
> >> Is there such a thing?
> >> and if not,any plans for this?
> >
> > First of all: 'unicode' is merely a table. The computer needs an
> > encoding. The LCL supports UTF-8. So, yes, there is already a unicode
> > LCL. Probably you want UTF-16 for wince.
>
> Maybe it's possible to use internally a type for unicode which is OS
> dependend. This requires a lot of code to be rewritten but it makes it
> possible to use native unicode type on platforms where utf-8 is uncommon.
The .lfm files are a lesser problem. The strings will eventually be
translated on the fly anyway.
But what means internally?
All public properties must have the same type on all platforms for 'Write
once compile anywhere'.
And it's not needed for say TEdit anyway, because drawing the new value
costs much more, than the conversion.
The only problem I see are the TStrings.
Maybe someone can make some tests, how much overhead is created by the
TStrings to UTF-16 conversion?
> >> Becouse while i was trying to make wince interfaces work,i see lots of
> >
> >> convertion to unicode,and it really makes these interfaces slow,which
> >by > the fact that all wince devices are rather slow,makes them
> >inefficient. >
> >> For example it is really pointless converting every tstrings to unicode
> >
> >> when some actions to winceapi is required and so on.
>
> OTOH, using widestrings always is usually bloat. Even more considering
> that modern PDAs are clocked with >600 MHz having only 64 MB of RAM ...
>
> >
> > For TStrings the overhead is indeed high, although O(n).
> > Do you have some ideas how to reduce the overhead?
Mattias
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
