Recent

Recent Posts

Pages: 1 2 [3] 4 5 ... 10
21
FindFirst/Next are system calls, so they are in the system codepage, which you can query.

No, the systemcalls add -file, e.g. findfirstfilea

findfirst/next/close are a Delphi wrapper for those calls.

And in FPC's case they also convert encoding since FPC 3.x. Originally concept and code written by Jonas(including differing between  defaultfilesystemcodepage and k defaultsystemcodepage), and then Michael and I implemented it for all targets.
22
So I have 2 questions:
 - what is the minimal Unit, which "switches" the charset returned by FindFirst / FindNext from ANSI to UTF8?

components/lazutils/lazutf8, but all units that depend on it will pull it in.

see https://wiki.freepascal.org/Lazarus_with_FPC3.0_without_UTF-8_mode for a workaround.

Quote
- is there a way (e.g. a function or global variable or conditional) to determine in a common unit (like "unit1"), whether this "switching" unit is used somewhere in the whole program so that FindFirst / FindNext returns UTF8 instead of ANSI?

Check defaultfilesystemcodepage for value $65001, if so, then it is utf8.

Quote
I'm a beginner to character sets and codepages. Thanks in advance. I attached my 2 small projects and a demo file with german special characters in the filename.

One warning/tip, don't rely on visuals if something is ok. Seeing umlaute doesn't mean it is ok. It is only ok if it is really IS the encoding you think it should be.

It is easy to get confused if you print some result (to console or file) and then the wrong encoding gets "corrected" by the console or notepad that might assume a different encoding then your problem. A simple workaround is to dump a string with an accent in the first few letters to file, and look at it with an hexeditor instead of notepad.
23
For more information about character set conversions see here: Unicode Support (reference for the System unit) and Unicode and codepage awareness (ref. for the SysUtils unit).

IIRC, the LCL makes some changes on startup so that all the internal processing is done in UTF-8, while the RTL (as used in console programs) remains mostly "agnostic" and uses RawByteString's to prevent any modification of the values returned by the OS.
24
General / Re: QT vs Lazarus
« Last post by lucamar on Today at 02:24:32 pm »
What one has to realize is that *all* the "standard" widgetsets depend on external libraries: GTK, Qt, Windows, Mac, ... and they are all rather "heavy"; it can't be otherwise since they have to be generic enough to catter to all kind of applications.

The perceived "heaviness" of, say, Qt or GTK arises only if you need or want to install/use them in environments in which they are not the "native GUI". In those cases they have to include lots of functionality which in their native Unix are implemented in the OS or the low-level graphic layers. Hence a GTK or Qt application will always appear slower and will display more "quirks" in, say, Windows than a "native" application.

Whether that matters or not is a question best left to the planning stage of each project and depends on lots of considerations: portability, responsiviness needed, etc. There's no one-size that fits all.
25
FindFirst/Next are system calls, so they are in the system codepage, which you can query.
26
In Germany we have 7 special characters, called "Umlaute". These are "Ä Ö Ü ä ö ü ß". They can occur in filenames.

If I write a simple console program (I use FPC 3.0.4 on Windows 7) then FindFirst / FindNext returns the ANSI charset:

Code: Pascal  [Select]
  1. unit unit1;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5. interface
  6.  
  7. procedure showfiles(pattern: ansistring);
  8.  
  9. implementation
  10.  
  11. uses sysutils;
  12.  
  13. function hexString(s: ansistring): ansistring;
  14.    {returns 's' as a hex-string}
  15.    var z: ansistring;
  16.        i: longint;
  17.    begin
  18.    z:=''; for i:=1 to length(s) do  z:=z + ' ' + hexStr(ord(s[i]),2);
  19.    exit(z);
  20.    end;
  21.  
  22. procedure showfiles(pattern: ansistring);
  23.    {shows all files which match to 'pattern'}
  24.    var SR: TSearchRec;
  25.    begin
  26.    if FindFirst(pattern,faAnyfile,SR) = 0 then
  27.       repeat writeln(SR.Name, hexString(SR.Name));
  28.       until  FindNext(SR) <> 0;
  29.    FindClose(SR);
  30.    end;
  31.  
  32. end.  

Code: Pascal  [Select]
  1. program project1;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5. uses unit1;
  6.  
  7. begin
  8. showfiles('d:\tst\xx_*.*');
  9. end.

The result for a file with special characters (file is attached) is ANSI:
Code: [Select]
>project1.exe
xx_äöüÄÖÜ.txt 78 78 5F E4 F6 FC C4 D6 DC 2E 74 78 74

But as soon as I write a (minimal) GUI application, using the same "unit1", FindFirst / FindNext returns now the UTF8 charset:

Code: Pascal  [Select]
  1. program project2;
  2.  
  3. {$mode objfpc}{$H+}
  4. {$apptype console} {neccessary for writeln}
  5.  
  6. uses
  7.  Interfaces, // this includes the LCL widgetset
  8.  unit1;
  9.  
  10. begin
  11. showfiles('d:\tst\xx_*.*');
  12. end.

The result for the same file with special characters is now UTF8:
Code: [Select]
>project2.exe
xx_äöüÄÖÜ.txt 78 78 5F C3 A4 C3 B6 C3 BC C3 84 C3 96 C3 9C 2E 74 78 74

So I have 2 questions:
 - what is the minimal Unit, which "switches" the charset returned by FindFirst / FindNext from ANSI to UTF8?
 - is there a way (e.g. a function or global variable or conditional) to determine in a common unit (like "unit1"), whether this "switching" unit is used somewhere in the whole program so that FindFirst / FindNext returns UTF8 instead of ANSI?

I'm a beginner to character sets and codepages. Thanks in advance. I attached my 2 small projects and a demo file with german special characters in the filename.
27
General / Re: QT vs Lazarus
« Last post by marcov on Today at 01:36:28 pm »
Maybe he means QTquick or what it is called nowadays. That had a js engine somewhere iirc.
28
General / Re: QT vs Lazarus
« Last post by PascalDragon on Today at 01:27:48 pm »
there is a difference LOL

Lazarus program >> OS Widgetset

Qt program >> Qt Widgetset (libs as virtual machine) >> OS Widgetset

where '>>' means 'rely on'

so on slow machines or when timing is important, forget Qt
Qt is not a virtual machine. It's just a widget set library like the LCL itself is with abstractions for the underlying operating system UI.
Also the LCL can use Qt as backend without problems (mainly used on Linux as an alternative to GTK, but it can be used on Windows and macOS as well).

unfortunatelly I had to work with Qt while I wasn't retired, SO I KNOW exactly what I am talking about  :P when I say "CONSIDER" Qt NEEEEEEDED libs as a virtual machine alike Crap eating resources, consuming machines' time

Okay, if you want a nice look and impress your users, AND you do not care resources nor time consuming, use Qt widgets. In other cases, DO NOT
I don't agree with you. I have worked with Qt as well. In fact I ported it to my company's operating system, so I know how Qt works internally. As my company's OS also has a user mode virtual machine for Windows and Linux I can definitely tell the difference between a virtual machine and a library abstraction that Qt (and the LCL) is.
29
General / Re: How? A Completely INDEPENDENT Copy of UnicodeString
« Last post by Thaddy on Today at 01:27:29 pm »
Yes. The case Marco describes does not fit your requirements. (But is a good thing to keep in mind!)
30
General / Re: Has anyone converted the C librarys to FreePascal?
« Last post by PascalDragon on Today at 01:25:38 pm »
What was wrong with that version, exactly? Doesn't it solve the problems people had with the "function-like" implementation?

Readability, more difficult to the point error generation (something that C/C++ obviously doesn't care about)
What do you mean with "point error generation"?
Pages: 1 2 [3] 4 5 ... 10