Re: Did Borland doing well in Q4? Listen to the Earning CC



In article <47cc14d4@xxxxxxxxxxxxxxxxxxxxxx>, DrDiettrich1@xxxxxxx
says...
Jolyon Smith wrote:

Because "String" will now mean "UnicodeString". No if's, not but's, no
choice.

Changing an type does not necessarily affect the application code.

No, but in this case it does!


Changing Byte to Integer or Int64 does not normally require further
adjustments. Why then for String?

Because a String is *very* different from any ordinal type.


If nothing else when your application goes Unicode "overnight", any data
entry validation you are performing is likely to be incomplete at best
and inadequate at worst.



So to _ensure_ that your ANSI application continues to behave correctly
AS an ANSI application you will need to change all "String" declarations
to "ANSIString" (and Char to ANSIChar and PChar to ANSIChar) etc.

Why that? Do the used controls and library functions still only accept
AnsiString?

Since that is all they have EVER accepted up to now you HAVE to assume
that this is the case.

Either declarations are in terms of "String", which today means
"ANSIString", or they are explicitly "ANSIString".

In the first case (String => implies ANSIString) you cannot guarantee
that the change from ANSIString -> UnicodeString will not have some
adverse affect without inspecting the internal implementation details of
the component/library itself.

In the latter case (explicit ANSIString) you can at least be sure that
it will not be unexpectedly broken when encountering UTF16 strings,
since it simply cannot actually happen. However, since your
interactions with the VCL will almost certainly (by default) be in terms
of UTF16 strings (i.e. "String") you will incur potentially lossy
conversions when passing those UTF16 strings into those ANSIString
routines.

I would hope that you will at least see compiler warning emitted
wherever your code passes a UnicodeString to an ANSIString parameter,
but then on the other hand, I can also see that leading to a deluge of
such warnings.


Now if all your components and libraries are current and supported,
great.

Not long after Tiburon is released you might hope to get a Unicode
"certified" update for those components and libraries. If it's an
orphan though, you are going to have make sure it's Unicode friendly
yourself.

Safer by far to simply preserve the ANSI perception of the world that
that component/library had - it's the only way to be absolutely
*certain* that it will behave and perform precisely as it did before.
.



Relevant Pages

  • Re: Did Borland doing well in Q4? Listen to the Earning CC
    ... AS an ANSI application you will need to change all "String" ... declarations to "ANSIString" (and Char to ANSIChar and PChar to ... Only THEN can you start thinking about how Unicode is best ... Even the specifically "ANSI" FS routines do not use ...
    (borland.public.delphi.non-technical)
  • Re: More on Unicode VCL
    ... This talks about a new unicode reference counted string which will become the default string type, but also discusses the problems of supporting C++. ... In general one only knows how to interpret the content of an AnsiString if the codepage is known. ... This is the whole point of Unicode, and IMO trying to use codepages to distinguish them will end in a big mess, since sometimes we know which codepage was used, sometimes we don't. ...
    (borland.public.delphi.non-technical)
  • Re: Another Cross Platform Delphi Tought
    ... Ctrl+Shift+J - much safer due the syntactical parser underneath. ... 'String' with 'AnsiString' and the all other cousins ... using which will not be Unicode "safe" until sometime after Tiburon is actually released. ...
    (borland.public.delphi.non-technical)
  • Re: Did Borland doing well in Q4? Listen to the Earning CC
    ... Because "String" will now mean "UnicodeString". ... Changing an type does not necessarily affect the application code. ... AS an ANSI application you will need to change all "String" declarations to "ANSIString" (and Char to ANSIChar and PChar to ANSIChar) etc. ...
    (borland.public.delphi.non-technical)
  • Re: D9 Critical version for Delphi
    ... In Win32 you must use third-party controls for Unicode ... and string is AnsiString instead of WideString. ... .NET TStringList and the rest are Unicode-aware, whereas in Win32 ...
    (borland.public.delphi.non-technical)