>> Borland may have made a change that will cause us to leave Delphi. The
>> change in strings is creating a near epic conversion for us. We use a
>> lot
>> of third party controls and apparently it was pretty common to
>> interchange
>> AnsiString with String as well as use functions like StrPas.
> Bad code.
I won't argue that it is bad form to interchange AnsiString and String, but
in many cases it is just a holdover from dealing with old Unicode problems.
In other situations it was one way of getting the job done... For example,
can't do this any longer (not my code):
MTime: Array[0..11] Of Char;
IntToOctStr(UnixDate, SizeOf(MTime), True, MemBuf);
CopyMem(@MemBuf[0], @MTime[0], SizeOf(MTime));
MTime[SizeOf(MTime) - 1] := #0;
In other places the functions themselves have to be reconciled. For
example, this requires a casting to work:
StrPas(@SomeString[1]);
>> So now we have
>> weeks of hacking through code casting, changing, etc. After our pilot
>> project to convert a small set of controls that normally would take about
>> ten minutes to upgrade to the latest Delphi over about three days. The
>> boss
>> is asking if we would be better off spending that time and money
>> converting
>> our client to C#. This could be the end for us using Delphi. Shame.
>
> Converting to C# would be tremendously more time consuming and you'll have
> the risk to introduce a huge number of bugs because not only will you
> change
> language but also all components and runtime.
True, but the boss sees a port as necessary at some point. So long as we
keep the product patched and low maintenance there isn't any justification
to move it. However, why spend a month upgrading objects and buying more
source when we can take that money and time and start on a port they see an
inevitable. Sort of like an old car that has a head gasket blown on it. Is
it worth it to put another $2000 in repairs into the old car or should you
just bite it off and take that money and use it as a deposit for a new one.
By creating additional work and in some cases substantial work, CodeGear has
opened the door for leaving them. Maybe not as bad as VB to VB.net but
worse than all that CLX crap they put in a few years back. A good example
for us is the XDom. It no longer exists, has a lot of old Unicode string
manipulation that needs to be redone and we use it all over the place. The
alternatives are to fix the old XDom (ouch), swich components to ADom or
some other control (ouch) or create our own XDom objects built on top of
another control (ouch). All of those options requiring new unit tests to be
written.
>> The big dumb question of the day is there any directive to turn off
>> UnicodeString or to force String to be defined the old way?
>
> Simply do a search and replace to change all occurences of String type to
> AnsiString type. The compiler will automatically convert AnsiString to
> UnicodeString when it is necessary. This will work altough you will not
> benefit from Unicode.
If only it were that easy. That is the tact we took on our test project,
but the samples above (and another couple dozen) required a programmer to
sit down and figure out the right course of action. If your app has no
strange old Unicode support or funky string manipulation, it probably wasn't
a big deal. However, we deal with a lot of encryption, compression and
multi-platform code so we have a lot of components that cost to upgrade or
are no longer in business so we have to upgrade/replace. It wouldn't even
be a conversation if Delphi had unified onto one string. I am sure there
are good reasons to have AnsiString, UnicodeString, etc but from our
standpoint making them all the same thing or a Defines that would have
allowed us to keep the backwards compatibility in a unit would have been
better.
__________________________________________________
Delphi-Talk mailing list -> [email protected]
http://lists.elists.org/cgi-bin/mailman/listinfo/delphi-talk
