Copying RawByteString byte by byte in Delphi XE

I just ran into a problem with XE that I never thought of before... copying a 
RawByteString to another byte by byte does not work on some Windows versions. 
The example below runs fine on an English Windows, but on a Windows with a 
Chinese locale (for example Traditional Hong Kong), it fails:


procedure TForm1.Button1Click(Sender: TObject);
var
   S1, S2, UTF8BOM: RawByteString;
   i: integer;
begin
   UTF8BOM := #$EF#$BB#$BF;
   S1 := UTF8BOM + '<html>TEST</html>';
   S2 := '';

   for i := 1 to length(S1) do
     S2 := S2 + S1[i];  //Does NOT work!
     //S2 := S2 + copy(S1,i,1);  //Does work

   showmessage(S1);
   showmessage(S2); //not equal to S1 on a Chinese locale
end;


To my understanding, a RawByteString is an AnsiString without a code page - 
exactly what I need for moving binary content. The "copy" function above seems 
to return another RawByteString with exactly 1 byte.

What happens internally when I use "RawByteString[index]" instead? Does this 
return an AnsiChar with implicit conversion? I expected it to return whatever 
kind of single-byte char without any conversion.

Alexander Halser
0
Alexander
2/20/2012 7:06:17 PM
embarcadero.delphi.nativeapi 1236 articles. 1 followers. Follow

13 Replies
2157 Views

Similar Articles

[PageSpeed] 47

Alexander wrote:

> copying a RawByteString to another byte by byte does not work on some
> Windows versions.

Yes, it does.  What you are not taking into account is that RawByteString 
(and every other AnsiString-based type) has a runtime-assigned codepage associated 
with the character payload.  You are not assigning any codepage to your data, 
so a default codepage gets used when you assign your RawByteString to a UnicodeString. 
 That default is not UTF-8, but your data is UTF-8 encoded, so you don't 
get the results you are expecting.  You need to call SetCodePage() on your 
RawByteString before you start passing it around, eg:

{code:delphi}
procedure TForm1.Button1Click(Sender: TObject);
var
  S1, S2, UTF8BOM: RawByteString;
  i: integer;
begin
  UTF8BOM := #$EF#$BB#$BF;
  S1 := UTF8BOM + '<html>TEST</html>';
  S2 := '';
  for i := 1 to length(S1) do
    S2 := S2 + S1[i];  //Does NOT work!
  SetCodePage(S1, 65001, False);
  SetCodePage(S2, 65001, False);
  ShowMessage(S1);
  ShowMessage(S2);
end;
{code}

Alternatively, use UTF8String instead of RawByteString, since UTF8String 
has a compile-time affinity for codepage 65001, eg:

{code:delphi}
procedure TForm1.Button1Click(Sender: TObject);
var
  S1, S2, UTF8BOM: UTF8String;
  i: integer;
begin
  SetLength(UTF8BOM, 3);
  UTF8BOM[1] := #$EF;
  UTF8BOM[2] := #$BB;
  UTF8BOM[3] := #$BF;
  S1 := UTF8BOM + '<html>TEST</html>';
  S2 := '';
  for i := 1 to length(S1) do
    S2 := S2 + S1[i];  //Does NOT work!
  ShowMessage(S1);
  ShowMessage(S2);
end;
{code}

> To my understanding, a RawByteString is an AnsiString without a code
> page

No.  Non-empty string values always have a codepage assigned, even RawByteString 
values.  What RawByteString does not have is a *compiler-time* codepage affinity. 
 A RawByteString payload has to have its codepage assigned at run-time, whether 
from other string that gets assigned to it, or by your own code manually. 
 Every other string type has a compile-time codepage affinity instead.

> exactly what I need for moving binary content.

No.  Despite its name, RawByteString (or any other string type, for that 
matter) is NOT well-suited for managing binary data.  Especially in D2009+ 
with the new codepage handling in strings.  There is no standard codepage 
available that will not mangle binary data if a character conversion occurs 
when assigning a RawByteString to other string types.  You really need to 
use a TBytes or a TStream for handling binary data instead.

> The "copy" function above seems to return another RawByteString with exactly
> 1 byte.

That is what you asked it to do.  You are copying from a RawByteString, which 
is an AnsiChar-based type, Sizeof(AnsiChar) is 1, and you asked Copy() to 
copy 1 character.  But your source RawByteString had no codepage assigned 
to it yet, so neither did your destination RawByteString.  When you then 
passed the RawByteString values to ShowMessage(), which only accepts UnicodeString 
input, they got converted to Unicode using the OS default Ansi codepage, 
not UTF-8.

> What happens internally when I use "RawByteString[index]" instead?

Exactly what you would expect it to do.  It accesses the raw AnsiChar value 
at the specified index, just like with any other AnsiString-based string 
type.

> Does this return an AnsiChar with implicit conversion?

No.

> I expected it to return whatever kind of single-byte char without any conversion.

That is exactly what happens.  That is not where you are losing your data, 
though.

--
Remy Lebeau (TeamB)
0
Remy
2/21/2012 6:25:41 PM
Thank you for your sound explanation, Remy!

You are right, an (S1 = S2) returns true here. Which is actually wrong... I 
understand that a ShowMessage does an implicit conversion, but when both strings 
are identical, I expected it to result in the same conversion. This is foiled by 
the codepage of the string.

And that codepage also disables other string functions such as pos(). Which is 
in fact what I needed here. In my example, a pos('<html>', S1) returns a 
different value than pos('<html>', S1).

Isn't there any string type that doesn't mess around with encoding? Setting code 
pages for all these RawByteStrings and testing them on Chinese computers is a 
PITA. This is a mess... :-(

Alex


On 21.02.2012 19:25, Remy Lebeau (TeamB) wrote:
> Alexander wrote:
>
>> copying a RawByteString to another byte by byte does not work on some
>> Windows versions.
>
> Yes, it does.  What you are not taking into account is that RawByteString
> (and every other AnsiString-based type) has a runtime-assigned codepage associated
> with the character payload.  You are not assigning any codepage to your data,
> so a default codepage gets used when you assign your RawByteString to a UnicodeString.
>   That default is not UTF-8, but your data is UTF-8 encoded, so you don't
> get the results you are expecting.  You need to call SetCodePage() on your
> RawByteString before you start passing it around, eg:
>
> {code:delphi}
> procedure TForm1.Button1Click(Sender: TObject);
> var
>    S1, S2, UTF8BOM: RawByteString;
>    i: integer;
> begin
>    UTF8BOM := #$EF#$BB#$BF;
>    S1 := UTF8BOM + '<html>TEST</html>';
>    S2 := '';
>    for i := 1 to length(S1) do
>      S2 := S2 + S1[i];  //Does NOT work!
>    SetCodePage(S1, 65001, False);
>    SetCodePage(S2, 65001, False);
>    ShowMessage(S1);
>    ShowMessage(S2);
> end;
> {code}
>
> Alternatively, use UTF8String instead of RawByteString, since UTF8String
> has a compile-time affinity for codepage 65001, eg:
>
> {code:delphi}
> procedure TForm1.Button1Click(Sender: TObject);
> var
>    S1, S2, UTF8BOM: UTF8String;
>    i: integer;
> begin
>    SetLength(UTF8BOM, 3);
>    UTF8BOM[1] := #$EF;
>    UTF8BOM[2] := #$BB;
>    UTF8BOM[3] := #$BF;
>    S1 := UTF8BOM + '<html>TEST</html>';
>    S2 := '';
>    for i := 1 to length(S1) do
>      S2 := S2 + S1[i];  //Does NOT work!
>    ShowMessage(S1);
>    ShowMessage(S2);
> end;
> {code}
>
>> To my understanding, a RawByteString is an AnsiString without a code
>> page
>
> No.  Non-empty string values always have a codepage assigned, even RawByteString
> values.  What RawByteString does not have is a *compiler-time* codepage affinity.
>   A RawByteString payload has to have its codepage assigned at run-time, whether
> from other string that gets assigned to it, or by your own code manually.
>   Every other string type has a compile-time codepage affinity instead.
>
>> exactly what I need for moving binary content.
>
> No.  Despite its name, RawByteString (or any other string type, for that
> matter) is NOT well-suited for managing binary data.  Especially in D2009+
> with the new codepage handling in strings.  There is no standard codepage
> available that will not mangle binary data if a character conversion occurs
> when assigning a RawByteString to other string types.  You really need to
> use a TBytes or a TStream for handling binary data instead.
>
>> The "copy" function above seems to return another RawByteString with exactly
>> 1 byte.
>
> That is what you asked it to do.  You are copying from a RawByteString, which
> is an AnsiChar-based type, Sizeof(AnsiChar) is 1, and you asked Copy() to
> copy 1 character.  But your source RawByteString had no codepage assigned
> to it yet, so neither did your destination RawByteString.  When you then
> passed the RawByteString values to ShowMessage(), which only accepts UnicodeString
> input, they got converted to Unicode using the OS default Ansi codepage,
> not UTF-8.
>
>> What happens internally when I use "RawByteString[index]" instead?
>
> Exactly what you would expect it to do.  It accesses the raw AnsiChar value
> at the specified index, just like with any other AnsiString-based string
> type.
>
>> Does this return an AnsiChar with implicit conversion?
>
> No.
>
>> I expected it to return whatever kind of single-byte char without any conversion.
>
> That is exactly what happens.  That is not where you are losing your data,
> though.
>
> --
> Remy Lebeau (TeamB)
0
Alexander
2/21/2012 9:46:37 PM
Sorry, typo:

A pos('<html>', S1) returns a different value than pos('<html>', S2). The second 
returns zero, because the opening bracked gets eaten by the three bytes before 
it, due to the implicit conversion.


On 21.02.2012 22:46, Alexander Halser wrote:
> Thank you for your sound explanation, Remy!
>
> You are right, an (S1 = S2) returns true here. Which is actually wrong... I
> understand that a ShowMessage does an implicit conversion, but when both strings
> are identical, I expected it to result in the same conversion. This is foiled by
> the codepage of the string.
>
> And that codepage also disables other string functions such as pos(). Which is
> in fact what I needed here. In my example, a pos('<html>', S1) returns a
> different value than pos('<html>', S1).
>
> Isn't there any string type that doesn't mess around with encoding? Setting code
> pages for all these RawByteStrings and testing them on Chinese computers is a
> PITA. This is a mess... :-(
>
> Alex
0
Alexander
2/21/2012 9:48:42 PM
Alexander wrote:

> You are right, an (S1 = S2) returns true here.

Correct, because that is just comparing the bytes without any regard to codepage.

> Which is actually wrong... I understand that a ShowMessage does an implicit 
conversion

Not ShowMessage() itself, but its UnicodeString parameter that you are assigning 
your RawByteString to.

> but when both strings are identical, I expected it to result in the
> same conversion.

If both strings use the same codepage, and get converted in the same manner, 
then yes.

> And that codepage also disables other string functions such as pos().

Pos() is overloaded to work with RawByteString data without performing any 
conversions.

> Which is in fact what I needed here. In my example, a pos('<html>',
> S1) returns a different value than pos('<html>', S1).

??  I assume you meant S2 in one of those?

> Isn't there any string type that doesn't mess around with encoding?

No.  ShortString and plain AnsiString use the OS default Ansi codepage.  
AnsiString(N) derived types (UTF8String, etc) other than RawByteString deal 
with compile-time codepages, whereas RawByteString deals in run-time assigned 
codepages.  Even UnicodeString deals with encodings (it is UTF-16 encoded, 
aka codepage 1200).  Whenever you deal with any kind of text, you have to 
deal with its encoding in order to process it correctly.  Delphi merely hide 
that from you and did not make it very apparent (and lead to a lot of bad 
practices through the years) until it made the switch to Unicode in D2009. 
 Now you HAVE to be more mindful of encodings, or you are going to lose data 
somewhere along the way.

> Setting code pages for all these RawByteStrings and testing them on
> Chinese computers is a PITA. This is a mess... :-(

It is not a mess.  You are just not using things correctly.  If you are on 
a Chinese computer and want to use Chinese encodings, then continue using 
AnsiString as-is, or switch to UnicodeString or UTF8String, or typedef your 
own AnsiString(N) aliases that use Chinese codepages explicitally.  You really 
should not be using RawByteString directly in variables.  RawByteString is 
not meant for that purpose.  The only place you should be using RawByteString 
is in function parameters that are Ansi encoding agnostic (namely, only when 
you operate on bytes without regard to any encodings).  Any AnsiString type 
can be passed to a RawByteString without performing a conversion, but the 
opposite is not true.  Assigning a RawByteString to any AnsiString type (other 
than another RawByteString) will perform a conversion to that's AnsiString's 
codepage affinity.

--
Remy Lebeau (TeamB)
0
Remy
2/21/2012 10:14:15 PM
Alexander wrote:

> A pos('<html>', S1) returns a different value than pos('<html>', S2).
> The second returns zero, because the opening bracked gets eaten by the
> three bytes before it, due to the implicit conversion.

There is no implicit conversion performed when calling Pos() on a RawByteString, 
because there is an overloaded version of Pos() that takes RawByteString 
parameters as input:

{code:delphi}
function Pos(const SubStr, Str: ShortString): Integer; overload;
function Pos(const SubStr, Str: UnicodeString): Integer; overload;
function Pos(const SubStr, Str: WideString): Integer; overload;
function Pos(const SubStr, Str: RawByteString): Integer; overload; // <-- 
here
{code}

--
Remy Lebeau (TeamB)
0
Remy
2/21/2012 10:22:35 PM
Remy

>It is not a mess. You are just not using things correctly.


I think you'll find that an awful lot of people disagree with you. It is a mess. A decision was made by Embarcadero to alter the string type and thus break an awful lot of code. Moans have been going on since D2009 about it. A new type (say UniString) could have been introduced but that would have meant Embarcadero having to do more work and maintain a bit more code. They chose not to and created a mess for anyone using string not in total accord with their definition.

As to using things correctly why should people have to jump through additional hoops to achieve the same end result?

I have worked in both typed and untyped languages and in my personal opinion they both suffer from the same lack of maintainability and level of bugs.

Roy Lambert
0
Roy
2/22/2012 10:49:30 AM
> {quote:title=Remy Lebeau (TeamB) wrote:}{quote}
> There is no implicit conversion performed when calling Pos() on a RawByteString, 

.... unless there is a string literal used in the Pos() call. The compiler will always prefer the unicode version in that case and convert the other string type.

{code}
var
  R: RawByteString;
begin
  ...
  Pos(R, 'Hallo'); // R is implicitly converted to UnicodeString
  // lea eax,[ebp-$08]
  // mov edx,[ebp-$04]
  // call @UStrFromLStr  <<<< here
  // mov eax,[ebp-$08]
  // mov edx,$00462160
  // call Pos
end;
{code}

--
Andreas Hausladen
0
Andreas
2/22/2012 11:36:33 AM
> {quote:title=Andreas Hausladen wrote:}{quote}
> > {quote:title=Remy Lebeau (TeamB) wrote:}{quote}
> > There is no implicit conversion performed when calling Pos() on a RawByteString, 
> 
> ... unless there is a string literal used in the Pos() call. The compiler will always prefer the unicode version in that case and convert the other string type.
> 
> {code}
> var
>   R: RawByteString;
> begin
>   ...
>   Pos(R, 'Hallo'); // R is implicitly converted to UnicodeString
>   // lea eax,[ebp-$08]
>   // mov edx,[ebp-$04]
>   // call @UStrFromLStr  <<<< here
>   // mov eax,[ebp-$08]
>   // mov edx,$00462160
>   // call Pos
> end;
> {code}
> 

There is QC for that http://qc.embarcadero.com/wc/qcmain.aspx?d=89000
But since it is marked as Extreme corner case I doubt it will ever get fixed.

Dalija Prasnikar
0
Dalija
2/22/2012 11:46:15 AM
Andreas wrote:

> ... unless there is a string literal used in the Pos() call. The
> compiler will always prefer the unicode version in that case and
> convert the other string type.

If it is, then that seems like a bug to me, because literals are supposed 
to be context sensitive.  If a literal and a RawByteString are passed to 
a function that takes only RawByteString parameters (which Pos() has an overload 
for), I would expect the compiler to convert the literal to a RawByteString, 
not a UnicodeString.

--
Remy Lebeau (TeamB)
0
Remy
2/22/2012 6:48:36 PM
That's the explanation! No, it doesn't convert the literal, it uses the Unicode 
version of Pos() instead.


procedure TForm1.Button1Click(Sender: TObject);
var
   S1, S2, UTF8BOM: RawByteString;
   i: integer;
   p1, p2: integer;
begin
   UTF8BOM := #$EF#$BB#$BF;
   S1 := UTF8BOM + '<html>TEST</html>';
   S2 := '';
   for i := 1 to length(S1) do
     S2 := S2 + S1[i];

   p1 := pos('<html>', S1);
   p2 := pos('<html>', S2);   //-> S2 treated Unicode with implicit conversion
   showmessage(format('p1=%d p2=%d', [p1,p2]));  //p1=4 p2=0 on Chinese OS!

   p1 := pos(RawByteString('<html>'), S1);
   p2 := pos(RawByteString('<html>'), S2);
   showmessage(format('p1=%d p2=%d', [p1,p2]));  //correct
end;


Well, there is at least a way to fix this without writing a parser... ;-)

Alexander



On 22.02.2012 19:48, Remy Lebeau (TeamB) wrote:
> Andreas wrote:
>
>> ... unless there is a string literal used in the Pos() call. The
>> compiler will always prefer the unicode version in that case and
>> convert the other string type.
>
> If it is, then that seems like a bug to me, because literals are supposed
> to be context sensitive.  If a literal and a RawByteString are passed to
> a function that takes only RawByteString parameters (which Pos() has an overload
> for), I would expect the compiler to convert the literal to a RawByteString,
> not a UnicodeString.
>
> --
> Remy Lebeau (TeamB)
0
Alexander
2/23/2012 12:27:35 PM
Thank you all for explaining this so well! Now I understand better what's 
happening. I think, many readers here will be surprised (I was, though I know 
about strings)...  so here is a quick *SUMMARY* for those who did not read 
through the details:

My first surprise was that a RawByteString may still undergo a conversion when 
assigned to another RawByteString, because even RawByteString has a codepage at 
runtime. The following example...

var
   S1, S2, UTF8BOM: RawByteString;
   i, p1, p2: integer;
begin
   UTF8BOM := #$EF#$BB#$BF;
   S1 := UTF8BOM + '<html>TEST</html>';
   S2 := '';
   for i := 1 to length(S1) do
     S2 := S2 + S1[i];  //Does NOT work!

.... results in S2 not being identical to S1. If you compare (S1 = S2) you get 
true as a result and the bytes are the same, but when you later convert the 
string, it converts differently because of a different codepage. This might work 
perfectly on an English Windows, but on a Windows with Chinese locale, the BOM 
char #$BF and the opening bracket of '<html>' make some sense together and 
collapse to a singe Chinese character, whenever an implicit conversion takes place.

The second mistake was in the Pos() function. There is an overloaded version for 
each type of string, including RawByteString. But the compiler chooses the 
version based on the first parameter. If the search term is a string literal 
(not uncommon), it uses the Unicode rather than the RawByteString version. This 
causes an implicit conversion and delivers unexpected results.

Example (continued from above)...

    p1 := pos('<html>', S1);
    p2 := pos('<html>', S2);   //-> S2 treated Unicode with implicit conversion
    showmessage(format('p1=%d p2=%d', [p1,p2]));  //p1=4 p2=0 on Chinese OS!

    p1 := pos(RawByteString('<html>'), S1);
    p2 := pos(RawByteString('<html>'), S2);
    showmessage(format('p1=%d p2=%d', [p1,p2]));  //correct
end;


Conclusion: be extremely careful when using raw single-byte strings for 
manipulating data.

Thanks to all who replied!

Alexander Halser
0
Alexander
2/23/2012 12:49:08 PM
Alexander Halser wrote:

> Thank you all for explaining this so well! Now I understand better what's 
> happening. I think, many readers here will be surprised (I was, though I know 
> about strings)...  so here is a quick SUMMARY for those who did not read 
> through the details:
> 
> My first surprise was that a RawByteString may still undergo a conversion when 
> assigned to another RawByteString, because even RawByteString has a codepage at 
> runtime. The following example...
> 
> var
>    S1, S2, UTF8BOM: RawByteString;
>    i, p1, p2: integer;
> begin
>    UTF8BOM := #$EF#$BB#$BF;
>    S1 := UTF8BOM + '<html>TEST</html>';
>    S2 := '';
>    for i := 1 to length(S1) do
>      S2 := S2 + S1[i];  //Does NOT work!
> 
> ... results in S2 not being identical to S1. If you compare (S1 = S2) you get 
> true as a result and the bytes are the same, but when you later convert the 
> string, it converts differently because of a different codepage. This might work 
> perfectly on an English Windows, but on a Windows with Chinese locale, the BOM 
> char #$BF and the opening bracket of '<html>' make some sense together and 
> collapse to a singe Chinese character, whenever an implicit conversion takes place.
> 
> The second mistake was in the Pos() function. There is an overloaded version for 
> each type of string, including RawByteString. But the compiler chooses the 
> version based on the first parameter. If the search term is a string literal 
> (not uncommon), it uses the Unicode rather than the RawByteString version. This 
> causes an implicit conversion and delivers unexpected results.
> 
> Example (continued from above)...
> 
>     p1 := pos('<html>', S1);
>     p2 := pos('<html>', S2);   //-> S2 treated Unicode with implicit conversion
>     showmessage(format('p1=%d p2=%d', [p1,p2]));  //p1=4 p2=0 on Chinese OS!
> 
>     p1 := pos(RawByteString('<html>'), S1);
>     p2 := pos(RawByteString('<html>'), S2);
>     showmessage(format('p1=%d p2=%d', [p1,p2]));  //correct
> end;
> 
> 
> Conclusion: be extremely careful when using raw single-byte strings for 
> manipulating data.
> 
> Thanks to all who replied!
> 
> Alexander Halser

Thank *you* Alexander for the summary!

Cheers
Tom


-- 
Tom Brunberg
firstname.surname@welho.com
0
Tom
2/23/2012 1:18:49 PM
Alexander wrote:

> My first surprise was that a RawByteString may still undergo a
> conversion when assigned to another RawByteString

No, it does not.  It undergoes a conversion when assigned to any other string 
type, but NOT when assigned to another RawByteString.  The whole point of 
RawByteString is that it dynamically inherits the codepage of whatever string 
is assigned to it (if a WideString or UnicodeString is assigned, a conversion 
always occurs).

> because even RawByteString has a codepage at runtime.

When you declare a RawByteString variable, it has no codepage assigned yet. 
 You have to call SetCodePage() to set that.  When assigning any string to 
a RawByteString, the string's copepage gets copied over as needed.

> UTF8BOM := #$EF#$BB#$BF;
> S1 := UTF8BOM + '<html>TEST</html>';
> S2 := '';
> for i := 1 to length(S1) do
> S2 := S2 + S1[i];  //Does NOT work!
> ... results in S2 not being identical to S1.

Works fine for me when I try it in XE2.  However, you do need to pay attention 
to this warning:

{code:delphi}
UTF8BOM := #$EF#$BB#$BF;
{code}

[DCC Warning] Project146.dpr(14): W1058 Implicit string cast with potential 
data loss from 'string' to 'RawByteString'

> If you compare (S1 = S2) you get true as a result and the bytes are the 
same,
> but when you later convert the string, it converts differently because of a
> different codepage.

Correct, because you did not assign the UTF-8 codepage to either RawByteString 
before then performing any conversions.


--
Remy Lebeau (TeamB)
0
Remy
2/23/2012 5:29:44 PM
Reply:

Similar Artilces:

Delphi XE / Delphi 2010
Hello! I noticed that Embarcadero® Delphi® 2010 Version is not on the list of products on Embarcadero page. Or is it still possible to buy it? Will RAD Studio XE compile programs written in Delphi 2010 without problems.? Thanks. Am 13.09.2010 09:04, schrieb Petra Nemec: > Will RAD Studio XE compile programs written in Delphi 2010 without problems.? As always you will probably have to recreate the projects as the import is still a bit -- special. Christian Hello! Does anybody know if it is still possible to get a Delphi2010 trial version (if yes where)? ...

Delphi 7 to Delphi XE
Have been using Delphi 7 for many moons ( have got later versions but never upgraded to ) My first problem is: Component Palette. in XE it is a small toolbar docked in top right in Delphi 7 it gives a large view of all the components. I am struggling to be able to cope/access my components.in Delphi XE. Can I make the component pallette tool bar the same size as Delphi 7, or is there a fast way to view/choose all available components in XE, that I have not spotted yet? Kind Regards, Robert. Hi, What I know is that in Delphi 2010 and XE you can choose between t...

Delphi 7 Copy Array of Byte to Variant [Edit]
Hello I'm using Delphi 7 and need to copy an array of byte to a variant. The use case is to copy a file on disk to a variant. What I doing now is shown below, but it would seem that the start of the file is not transferred to the variant correctly: The buffer which contains the file would seem to be ok but there is something wrong with the variant. Thanks in advance for any help. Paul var afile: file of byte; buffer: array of byte; i: Integer; vv : variant; begin // read the file into an array of byte AssignFile(afile, LocalPath+LocalFile...

Migrating to Delphi XE from Delphi 7.0
Below is my code in Delphi 7.0, this is how to call another units in webmodule... Hello All, I create a web application in Delphi 7.0, using the Web Server Application, CGI, IntraWeb 7.0.15. And I used TIWPageProducer to view like this url "http://localhost/mcr/mcr.exe/main". I built and run. I viewed in thru IIS and it is running... This is my code in Delphi 7.0 .... .... procedure TWebModule1.proMainGetForm(ASender: TIWPageProducer; AWebApplication: TIWApplication; var VForm: TIWPageForm); begin VForm := TfrmMain.Create(AWebApplication); end;...

Migrating to Delphi XE from Delphi 7.0
Below is my code in Delphi 7.0, this is how to call another units in webmodule... Hello All, I create a web application in Delphi 7.0, using the Web Server Application, CGI, IntraWeb 7.0.15. And I used TIWPageProducer to view like this url "http://localhost/mcr/mcr.exe/main". I built and run. I viewed in thru IIS and it is running... This is my code in Delphi 7.0 .... .... procedure TWebModule1.proMainGetForm(ASender: TIWPageProducer; AWebApplication: TIWApplication; var VForm: TIWPageForm); begin VForm := TfrmMain.Create(AWebApplication); end; procedure TWebModule1....

Migrate from Delphi 2007 for Win32 to Delphi XE
we use Delphi 2007 for Win32 to support legacy (32Bit) OWL-based pascal applications (yes i know it was a mistake not to switch to VCL 15 years ago). could our applications still be opened and compiled with Delphi XE? The existing projects are all plain Pascal-Code, coming back from the times of Turbo Pascal for Windows and later on Borland Pascal. Are there any improvements we could profit from (i.e IDE, Debugger)? Thanks Andrej > {quote:title=Andrej Dimic wrote:}{quote} > could our applications still be opened and compiled with Delphi XE? I'm not sure, but I guess ...

Error on Delphi 6 but not on Delphi Xe for Ftp
I am Experimenting with get a file from our webside server via Ftp. I have 2 Machines 1 a laptop runing XP Delphi 6 Indy 10.5.8.0 An a machine runing Window 7 Delphi XE2 with Indy 10.5.8.0. I am using the Same Code on Both. procedure TFrmMain.ProcessItemDalySpecial; var PathDest : String; FileName : String; begin with FrmTb2 do begin if ReadIniBoolean(IniCfg,'FTP','UseFtpDaly') then begin Ftp.Host := ReadIniStr(IniCfg,'FTP','HostDaly'); Ftp.Port := ReadIniInt(IniCfg,'FTP'...

Delphi 7.0 code convert to delphi XE ...
Hello All, I create an application using Web Server Application then CGI stand alone... In WebModule I add ModuleController component and IWPageProcedure... Below is my code in Delphi 7.0, this is how to call another units in webmodule... .... .... procedure TWebModule1.proMainGetForm(ASender: TIWPageProducer; AWebApplication: TIWApplication; var VForm: TIWPageForm); begin VForm := TfrmMain.Create(AWebApplication); end; procedure TWebModule1.proLogInGetForm(ASender: TIWPageProducer; AWebApplication: TIWApplication; var VForm: TIWPageForm); begin VForm := TfrmLogIn.Create(AWebA...

Delphi and Delphi for .Net
It seems that Delphi for .Net is slower than Delphi Win32 native applicaiton. I would like to know is it true all .Net application is slower than Win32 native applicaiton or it is Delphi for .Net only. Your information is great appreciated, Inung On 2011-06-21 18:20:17 +0100, Inung Huang said: > It seems that Delphi for .Net is slower than Delphi Win32 native applicaiton. > I would like to know is it true all .Net application is slower than > Win32 native applicaiton or it is Delphi for .Net only. If you are only running the code in the application once then, yes, yo...

Delphi XE
Hi, Last week, I downloaded an evaluation copy of Delphi and installed it on my laptop (from this link) https://downloads.embarcadero.com/free/delphi I am able to create a simple VCL Forms application, drop a few VCL components onto the form and compile it without any problems. But when I next add the following code, compile and run it it keeps failing with: uses ExtActns; {$R *.dfm} function Download_HTM(const sURL, sLocalFileName : string): boolean; begin Result := True; with TDownLoadURL.Create(nil) do try URL:=sURL; Filename:=sLocalFileName; try...

byte[] and byte[][] in datawindow
I am getting a byte[] from the Jaguar component which I apply to the jDataWindowControl in PowerJ using setFullState(byte[]). How do I send any changes to this datawindow to the Jaguar component. The getFullState(byte[][]) requires a 2dimensional byte array. Replied to your post in the PowerJ DataWindow group, which seem like the most appropriate place for the question. Please try to avoid double-posting. Mark Maslow GDI <shalabhgoel@hotmail.com> wrote in message news:QNHQWJ$R$GA.164@forums.sybase.com... > I am getting a byte[] from the Jaguar component whi...

Delphi 7 to Delphi XE: TBlobField to XML [Edit]
Hi, I'm migrating a Delphi7 application to Delphi XE. I'm using a TClientDataSet to communicate, by using a XML frame, with my server. In this TClientDataSet I'm using a TBlobField which is an array of 384 byte. The blobField is allocate by a code like this : {code} myStream : TStream; myStream := aClientDataSet.CreateBlobStream(myBlobField, bmwrite); vResult := myStream.Write(ArrayOf384Byte[0], length(ArrayOf384Byte)); //vResult = 384 => GooD ! (...) {code} For communicate with the server, we have to decode the Blobfield in XML before to sending it. We have...

Any difference between Delphi Prism 2011 and Delphi Prism XE?
Looking at the features in Delphi Prism XE, they look the same as the new items in the 2011 release back in may. I there anything new in the XE release? or did they simply change the product branding? Just wondering if I need to update it or now when i download the rest. Thanks, Hi Dan, > Looking at the features in Delphi Prism XE, they look the same as the new items in the 2011 release back in may. I there anything new in the XE release? or did they simply change the product branding? Just wondering if I need to update it or now when i download the rest. See http://w...

Migrating from Delphi 6 to Delphi XE 3! [Edit]
All, I am a Delphi developer working in an windows form application developed using Delphi 6. Now, we are planning to upgrade the development tool. Can anyone provide me information related to major roadblocks that we can face while migrating from Delphi 6 to Delphi XE 3? Should we migrate to Delphi XE 3 or any other preferred version of Delphi based on the fact that our target users will be using Windows 7 or Windows 8? Do we have any tools or utilities to migrate the source code from Delphi 6 to higher version of Delphi? Also, any suggestions related to best practices are welcome....

Web resources about - Copying RawByteString byte by byte in Delphi XE - embarcadero.delphi.nativeapi

Use AnsiString And UTF8String In Delphi XE5 Firemonkey On Android And IOS
Embarcadero disabled access to byte stings in Delphi XE5 Firemonkey and if you're a long time Delphi developer you may be missing them. They ...

Unofficial ByteStrings Patch To Enable AnsiString Support In Delphi XE8 Firemonkey On Android And IOS ...
Developer Andreas Hausladen has released an updated version of his patch for System.ByteStrings which gives you access to PAnsiChar and other ...

Resources last updated: 12/1/2015 6:16:33 AM