On Fri, Apr 13, 2012 at 1:21 PM, Jürgen Hestermann <juergen.hesterm...@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 -- _______________________________________________ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
