[DUG] String Concatenation

[Rohit Gupta]

John,

no, I escaped to D7 as fast as I could  :-)
There were other problems with D5 to do with clientdataset.

John Bird wrote:

>That might explain something I found once when code in D5 like
>
>   teststr:=uppercase(trim(line));
>
>Would produce unpredictable stuff in the string teststr in one program
>consistently, yet if I removed the trim or prcessed the string a different
>way it worked,  yet this sort of code works in other places as expected.  
>
>Do you have references to what to look out for in D5?
>
>John 
>
>
>-----Original Message-----
>From: delphi-bounces at ns3.123.co.nz [mailto:delphi-bounces at ns3.123.co.nz] On
>Behalf Of Rohit Gupta
>Sent: Friday, 4 November 2005 12:51 p.m.
>To: NZ Borland Developers Group - Delphi List
>Subject: Re: [DUG] String Concatenation
>
>
>You havent mentioned what version you are using.  D5 has a severe 
>problem where it gets confused between shortstring and ansistring.  It 
>just shows up at random, when you examine the assembler code, you can 
>see the fault.  The only solution I found was to explicitly declare 
>ansistring and shortstring instead of using string.  Of course thsi 
>still stuffs up because all vcl uses string.
>
>I havent had any problems with D7 or D2005.
>
>You dont have any timers or events stuffing things up ? 
>
>Note you really wanted maxDataIndex-1
>
>Allan, Samuel wrote:
>
>  
>
>>We have a weird problem where we are building a string up. It is quite
>>a large string, but not exceptionally large. About maybe 1000 
>>characters. The code to create the string approximates:
>> 
>>insertString, finalString: string;
>> 
>>for i := 0 to maxDataIndex do
>>   insertString := insertString + dataItem[i];
>> 
>>finalString := CONSTANT_A + insertString + CONSTANT_B + insertString +
>>CONSTANT_C;
>> 
>>Without throwing an overflow warning or any other warning, this code
>>results in a finalString where the first instance of insertString is 
>>whole and complete. The second instance is interrupted half-way by 
>>what looks like a random memory dump, and there is no CONSTANT_C 
>>afterwards. insertString remains pristine and untouched.
>> 
>>We have also tried several variations on the above code:
>> 
>>Using Copy() to create two additional strings, one for each insert.
>>Same result for finalString, both additional insert strings are fine.
>> 
>>Putting placeholder tokens in the finalString, then running
>>StringReplace(). Same result.
>> 
>>We tried to isolate the code in a separate application. The separate
>>application works fine, as you would expect. So we think it may be 
>>something to do not with the code itself, but with the structure of 
>>our application. However, code like this is widely used within this 
>>application and elsewhere works fine.
>> 
>>Our application implicitly compiles several packages into itself. The
>>code in question is in one of these packages. So compiling any change 
>>to it requires compiling the package, then compiling the application.
>> 
>>We have searched the web, and found an exact match for this posted in
>>some newsgroup in 1998, but there were no responses. The match does 
>>not mention packages however.
>> 
>>
>>-----------------------------------------------------------------------
>>-
>>
>>_______________________________________________
>>Delphi mailing list
>>Delphi at ns3.123.co.nz http://ns3.123.co.nz/mailman/listinfo/delphi
>> 
>>
>>    
>>
>
>
>_______________________________________________
>Delphi mailing list
>Delphi at ns3.123.co.nz http://ns3.123.co.nz/mailman/listinfo/delphi
>
>_______________________________________________
>Delphi mailing list
>Delphi at ns3.123.co.nz
>http://ns3.123.co.nz/mailman/listinfo/delphi
>
>
>
>  
>