<p>Am 09.06.2016 14:30 schrieb "José Mejuto" <<a href="mailto:joshyfun@gmail.com">joshyfun@gmail.com</a>>:<br>
><br>
> El 09/06/2016 a las 8:04, Sven Barth escribió:<br>
><br>
>>> {$DEFINE THISDONTCOMPILE}<br>
>>>   TConstRecord: TFirstRecord = (<br>
>>>   {$IFDEF THISDONTCOMPILE}<br>
>>>     Ident: TSomePcharArray[1]<br>
>>>   {$ELSE}<br>
>>>     Ident: @TSomePcharArray[1]<br>
>>>   {$ENDIF}<br>
>>>   );<br>
><br>
><br>
>> One can only use untyped constants to initialize other constants or<br>
>> variables in their declarations. The TsomePCharArray is a typed<br>
>> constant, thus not suitable for assignments (a pointer to it's element<br>
>> is however legal as you noticed).<br>
><br>
><br>
> Hello,<br>
><br>
> The strange thing is that if I use a pointer, an integer or any other type instead a Pchar the error message is completely different "Error: Can't read or write variables of this type" which is a bit more informative.<br>
><br>
> I understand that untyped is the only source for assign a constant to so using @ I get an untyped pointer and the assign is performed, but is there a way to convert a pointer (typed) to untyped one ?</p>
<p>Typed and untyped pointer have nothing to do with this. It's about typed and untyped constants. And addresses to variables and typed constants are by definition untyped constants as well.</p>
<p>> I think that the solution is to pollute the symbol table with a lot of consts, one of each text string.<br>
><br>
> Thank you for your help and enlightenment.</p>
<p>You're welcome.</p>
<p>Regards,<br>
Sven</p>