[Lazarus] TProcess, UTF8, Windows

[Marcos Douglas]

On Fri, Apr 13, 2012 at 1:21 PM, Jürgen Hestermann
<juergen.hestermann at gmx.de> wrote:
> Mattias Gaertner schrieb:
>
>>> But if you use a function from a (Free Pascal or Lazarus) library it is
>>> not clear which kind of encoding this function expects. As I already
>>> mentioned, for example CopyFile (from LCL) and FindFirst (from SysUtils)
>>> have no hint in their documentation on what encoding is expected. I
>>> know, somewhere it says that library x has enconding y but why wasn't
>>> this information written to the documentation for the indiviudal
>>> functions?
>>
>> Normally defaults are not explained for every function of a
>> unit/package.
>
> ??? What defaults? The topic is string encoding not defaults.
>
>
>
>> Feel free to add the encoding to those functions you think it is not
>> clear and send a patch.
>
> I would like to. But how do I get the information? You see the vicious
> circle?
> Or do you mean I should find out the encoding by trial and error for each
> function
> myself (bulding a test program around them) because this is the only way to
> get it?
> Who wants to program with such a programming language where encoding for
> function parameters is not documented?
> It seems it's for the hard core developers only.
>
>
>
>> A volunteer project like Lazarus requires the help of volunteers.
>
> Yes. If you send me a list of the expected/used string encoding for *all*
> function parameters then I can add this information to the documentation
> when I find out how to do that. How can I change it here:
> http://lazarus-ccr.sourceforge.net/docs/lcl/fileutil/copyfile.html
>
> ?
>
>
>>> That's not what we are talking about here. If I understood Marcos
>>> problem correctly the topic was the output of another function where the
>>> encoding was unclear.
>> What function are you talking? Have you read the example Marcos used?
>
> Well, I was mainly talking about any string parameter to any function in
> any library that comes with Free Pascal and/or Lazarus and I was under the
> impression that Marco's problem was based on the same issue: A string
> parameter
> is required ("Memo1.Lines.Append") but it is not clear what encoding is
> expected.
> This isssue exists for *all* functions of Free Pascal and Lazarus that
> expect
> strings as parameters. I already mentioned the example of CopyFile:
> To my astonishment the function CopyFile not only exists in the unit Windows
> (where
> I expected it) but also in the LCL (with different string encoding). The
> same applies to
> FindFirst and other file functions.

IMHO, I think all functions (even classes) should be a prefix or use
the own unit as a prefix, for these conflicts do not exist. Only FPC,
the compiler, could be use "simple" names like CopyFile.

Examples
CopyFile (FPC)
LazCopyFile (LCL)

Just using a better organization. But these tips continues allowing
declare CopyFile in my own sources so, should have mandatory to use
unit as a prefix -- and should exists a sintaxe do use an "alias"
(readable names) to units.

Marcos Douglas