<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Once upon a time, on 01/07/2013 02:17
PM to be precise, Michael Schnell said:<br>
</div>
<blockquote cite="mid:50EACAD3.7030404@lumino.de" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
So the ambiguity with <u>filling</u> a string with data in fact
arises when <u>not</u> using the #nn notation <span
class="moz-smiley-s1"><span> :-) </span></span>. With #nn the
effect (i.e. the resulting binary) is obvious.<br>
</blockquote>
Well, if there is literally the sequence $C7, $BE in your source
code (that is, open up a hex editor and actually see the values
there, as one byte each) that would also do the same, as the
compiler will default to one byte strings I think. The only issue
with this is that you also need to set your code editor to the
encoding you want 'cause otherwise it will screw up the display and
possible binary value of the character.<br>
<br>
So, yes I would say the #nn notation is probably the safest to use,
also handy if your character contains (or is) something that `cannot
be there`, like a newline: #10 (or #13#10 under windows)<br>
<br>
Also, if you use a literal utf-16 char in the code (so no #nnnn, but
the actual character) I think the {$codepage utf16} directive might
come in handy, as otherwise the compiler will interpret this series
of bytes as sperate single bytes characters. This is however not an
issue with the #nnnn notation, as there is no ambiguity with this
interpretation.<br>
<pre class="moz-signature" cols="72">--
Ewald
</pre>
</body>
</html>