Formulare und deren Namen

[fliegermichl]

Warum das Projektkürzel?

Das ist absolut notwendig!
Insbesondere wenn die Unit Bestandteil eines Packages ist. Lazarus schmeisst die unmöglichsten Fehlermeldungen, wenn zwei Packages Dateien mit gleichem Namen haben.

[PascalDragon]

@wp_xyz:
Wenn man bei Linux anscheinend nur Kleinbuchstaben verwenden darf, gibt das natürlich nicht wirklich Sinn
die Dateien nach meinem Stil umzubenennen. Dann ist nämlich vorbei mit plattformunabhängig, stimme ich Dir vollkommen zu.
Das wuste ich garnicht, da ich noch nie mit Linux zu tun hatte. Seit ca. 35 Jahre Windows Qäulerei...
Mit den Unit Namen schaue ich mir gleich nochmal genauer an. Danke Dir für die ausführliuche Info.

Es hat erstmal nichts direkt mit Windows vs. Linux zu tun, sondern damit, ob die meisten Dateisysteme auf dem jeweiligen Betriebssystem Case Insensitive, Case Preserving oder Case Sensitive sind.

Unter Windows sind sowohl NTFS als auch FAT Case Preserving, das heißt wenn ich eine Datei "FooBar" nenne, dann bleibt die auch "FooBar", kann sie aber auch als "fOObAR" ansprechen. Bei Case Insensitive (FAT ohne Long Names) wird mein "FooBar" immer zu "FOOBAR" und wenn ich die Datei mit "foobar" anspreche, bekommen ich trotzdem "FOOBAR". Bei Case Sensitive Dateisystemen (wie Ext2/3/4, BtrFS oder XFS), wenn du eine Datei "FooBar" hast, dann wird die auch nur über "FooBar" zurückgegeben, bei "foobar" gibt es dann entsprechend eine Datei nicht gefunden Fehlermeldung.

Ausflug: NTFS unterstützt auch ein Case Sensitive Verhalten (global wie auch seit Windows 10 ordnerspezifisch) wie auch Ext4 ein Case Insensitives Verhalten (ordnerspezifisch) unterstützt. Da kann man dann auch viel Spaß mit Programmen haben, die das dann nicht korrekt beachten.

Was hat das nun mit FPC zu tun? Ganz einfach: der Compiler hat erstmal nur die Schreibung des Unitnamens, wie du ihn in der uses-Sektion angegeben hast, um nach ihn zu suchen. Wenn du da nun also "FooBar" stehen hast, dann sucht der Compiler wie folgt in den Suchpfaden:
- gibt es "FooBar"? (also as-is)
- gibt es "foobar"?
- gibt es "FOOBAR"?

Auf einem Case Insensitive oder Preserving Dateisystem wird die Datei beim ersten Mal bereits gefunden, solange die ganzen Buchstaben enthalten sind. Auf einen Case Sensitive Dateisystem wird die Datei aber nur gefunden, wenn genau eine der drei Schreibungen gefunden wird. Wenn also nun "Foobar" statt "FooBar" in der uses-Sektion steht, die Datei aber "FooBar" heißt, dann kann sie nicht gefunden werden.

Wenn du also nun immer schön brav genau das gleiche Casing für deine Units nutzt oder nur auf einem Case Insensitive/Preserving Dateisystem unterwegs bist, dann kannst du die Option von Lazarus umschalten. Ansonsten wird es strengstens empfohlen die IDE diese Convenience Funktion übernehmen zu lassen, da dies eventuelles Fluchen oder Verwundern in der Zukunft vermeidet.

Warum das Projektkürzel?

Das ist absolut notwendig!
Insbesondere wenn die Unit Bestandteil eines Packages ist. Lazarus schmeisst die unmöglichsten Fehlermeldungen, wenn zwei Packages Dateien mit gleichem Namen haben.

Seit FPC 3.0.0 kann man auch noch Dotted Unit Names nutzen: datalogger.uart.pas. Seit 3.2.0 kann man auch Default Namespaces angeben (also hier zum Beispiel -FNdatalogger).

[Timm Thaler]

Ich mein, was auch immer die geraucht haben, dass sie bei Linux Case-sensitive Dateinamen verwenden: Aus diesem Grund sind meine Units immer in Kleinbuchstaben.

[PascalDragon]

Das hat nichts mit Linux zu tun, sondern geht weiter zurück, da bereits das alte Unix File System Case Sensitive war. Letztlich haben das alle Unix-artigen Betriebssystem (Linux, BSD, Minix, Solaris) davon geerbt (macOS ist hier ein wenig speziell, da es nicht nur BSD-like ist, sondern auch vom klassischen MacOS erbt, das ebenfalls Case Insensitive war).

Es hat dabei den Vorteil, dass du einerseits Groß-/Kleinschreibung in Dateinamen haben kannst, aber trotzdem eine schnelle Dateisuche haben kannst, da du nicht in verschiedenen Schreibweisen schauen musst (vor allem auf den damaligen Systemen war das durchaus ein Performancevorteil). FAT kannte ursprünglich ja nur ASCII, also war das kein großes Problem, aber vor allem heutzutage bei der Verwendung von Unicode kann das sehr ekelhaft werden, da je nach Locale sich die Groß-/Kleinschreibung unterscheidet (zum Beispiel ist im Deutschen die große Form von i das I, aber im Türkischen ist es das İ (großes I mit Punkt oben)). NTFS und HFS+ lösen das zum Beispiel durch Conversion Tables, die eben nicht abhängig von der Locale sind, also eventuell beim Nutzer zur Verwirrung führen könnten.

Nebenbei erwähnt: die Mehrheit der Dateisysteme ist Case Sensitive.

[Timm Thaler]

Das hat nichts mit Linux zu tun, sondern geht weiter zurück, da bereits das alte Unix File System Case Sensitive war.

Was aber kein Grund ist, das nicht zu ändern. Zumal es inkonsistent umgesetzt ist: Kleinschreibung und Großschreibung werden zwar differenziert, aber in der Dateiliste stehen sie wieder gemischt und nicht in Reihenfolge ihres ASCII-Wertes.

Und dass es nicht Userfreundlich ist sieht man wenn man mal durch die Linux-Dateistruktur schaut: Es wird dann halt Alles kleingeschrieben.

Es hat dabei den Vorteil, dass du einerseits Groß-/Kleinschreibung in Dateinamen haben kannst, aber trotzdem eine schnelle Dateisuche haben kannst, da du nicht in verschiedenen Schreibweisen schauen musst

Muss man nicht. Man konvertiert Suchstring und Fileliste zu Uppercase und kann direkt vergleichen.

[PascalDragon]

Das hat nichts mit Linux zu tun, sondern geht weiter zurück, da bereits das alte Unix File System Case Sensitive war.

Was aber kein Grund ist, das nicht zu ändern.

Mag sein, aber es gibt auch keinen Grund es zu ändern.

Zumal es inkonsistent umgesetzt ist: Kleinschreibung und Großschreibung werden zwar differenziert, aber in der Dateiliste stehen sie wieder gemischt und nicht in Reihenfolge ihres ASCII-Wertes.

Das ist aber auch nur wie es sich mittlerweile repräsentiert. Ursprünglich hat ls es einfach nur in der Reihenfolge rausgehauen, wie sie im Dateisystem waren. Dann gab es ne Phase (die ich sogar auch noch mitbekommen habe), wo es tatsächlich nach ASCII Wert sortiert war. Heutzutage ist der Standard von ls die Liste Case Insensitive zu sortieren.

Es hat dabei den Vorteil, dass du einerseits Groß-/Kleinschreibung in Dateinamen haben kannst, aber trotzdem eine schnelle Dateisuche haben kannst, da du nicht in verschiedenen Schreibweisen schauen musst

Muss man nicht. Man konvertiert Suchstring und Fileliste zu Uppercase und kann direkt vergleichen.

Und wie ich geschrieben habe mag das zwar mit ASCII sehr einfach gehen, aber bei Unicode gibt es da gewisse Schwierigkeiten.

[Winni]

Hi!

In der Unit LazUTF8 gibt es

Code: Alles auswählen

function UTF8CompareStrCollated  (const S1, S2: string): PtrInt;

die auch die Eigenheiten der verschiedenen Sprachen berücksichtigt.

Winni

[Timm Thaler]

Mag sein, aber es gibt auch keinen Grund es zu ändern.

Das stimmt, Usability war bei Linux nie ein Grund was zu ändern.

Das ist aber auch nur wie es sich mittlerweile repräsentiert. Ursprünglich hat ls es einfach nur in der Reihenfolge rausgehauen, wie sie im Dateisystem waren.

Nur weil es am Anfang schlecht war muss man das nicht zum Standard machen. Computer sind für Menschen da, nicht umgekehrt.

Und wie ich geschrieben habe mag das zwar mit ASCII sehr einfach gehen, aber bei Unicode gibt es da gewisse Schwierigkeiten.

Unicode hat seit 30 Jahren Casefold-Attribute. Das sagt Dir sogar genau, welches Zeichen die Groß/Klein-Entsprechung eines Zeichens ist. Im Gegensatz zu ASCII.

[PascalDragon]

Und wie ich geschrieben habe mag das zwar mit ASCII sehr einfach gehen, aber bei Unicode gibt es da gewisse Schwierigkeiten.

Unicode hat seit 30 Jahren Casefold-Attribute. Das sagt Dir sogar genau, welches Zeichen die Groß/Klein-Entsprechung eines Zeichens ist. Im Gegensatz zu ASCII.

Das hängt aber eben von der Locale/Collation ab. Im Deutschen verhält es sich anders als im Türkischen zum Beispiel. Das heißt entweder machst du's in der Anwendung, wo du auch wirklich die Locale verfügbar hast (quasi das was ls macht) oder du machst es im Dateisystemtreiber, dann hast du nicht notwendigerweise die Locale verfügbar und verlässt dich auf die Case Conversion Tables, die im Dateisystem integriert sind (NTFS, HFS+, APFS) und hast dann eventuell Sortierungen, die für den Anwender verwirrend sind.

[siro]

Ich habe grade etwas festgestellt beim Umbennen meiner Dateien:

Bei einem neuen Projekt habe ich immer eine .lpr Datei

Im Prinzip ist das der Pascal Source für das Hauptprogramm. Hab ich zumindest so verstanden.

Wenn ich die Datei lade und dann "Speichern Unter" zum Beispiel main ablege,
dann wird aus der .lpr Datei eine .pas Datei.
Wenn ich nun in der IDE Project .lpr Datei anzeigen klicke, öffnet er die Datei main.pas

Eine .lpr benötigt er anscheinend garnicht mehr, ich hab die mal weggelöscht.

Verstehe ich jetzt nicht wirklich, wozu es die .lpr dann gibt, aber zumindest funktioniert alles richtig.
Bekommt natürlich den Namen, wie das Projekt (die .exe) mal heissen soll:

Jetzt bekomme ich endlich eine gewisse Struktur rein:

Code: Alles auswählen

program KEL103_V4;

{$mode objfpc}{$H+}

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Interfaces, // this includes the LCL widgetset
  Forms, frm_main, frm_batttest, frm_curves;

{$R *.res}

begin
  RequireDerivedFormResource:=True;
  Application.Scaled:=True;
  Application.Initialize;
  Application.CreateForm(TFormMain, Form_Main);
  Application.CreateForm(TForm_Batterietest, Form_Batterietest);
  Application.CreateForm(TFormCurves, Form_Curve);
  Application.Run;
end.
                           

die Dateinamen bleiben weiter mit Kleinbuchstaen:
frm_batttest.lfm
frm_batttest.pas
usw...

[wp_xyz]

Wenn ich die Datei lade und dann "Speichern Unter" zum Beispiel main ablege,
dann wird aus der .lpr Datei eine .pas Datei.
Wenn ich nun in der IDE Project .lpr Datei anzeigen klicke, öffnet er die Datei main.pas

Eine .lpr benötigt er anscheinend garnicht mehr, ich hab die mal weggelöscht.

Die lpr-Datei ist eine "normale" Pascal-Datei, die durch die Endung .lpr hervorgehoben ist, weil sie die zentrale "Programm"-Datei ist. Der Dialog "Datei" > "Speichern unter" ist eigentlich für Units gedacht, und diese haben die Endung .pas oder .pp. Wenn du hier die lpr-Datei unter anderem Namen speicherst, erhält sie somit die Endung .pas (oder .pp) - das ist aber kein Problem, Lazarus akzeptiert das, solange die lpi-Datei vorhanden ist, in der alle Projektdateien stehen, und der Inhalt bleibt unverändert. Allerdings wäre mir das viel zu unübersichtlich, weil diese wichtige Datei dann nicht mehr von den Units zu unterscheiden ist.

Wenn du das Projekt unter anderem Namen speichern möchtes, ist es besser den Befehl "Projekt" > "Projekt speichern unter" zu verwenden, denn dann wird auch die lpi-Datei umbenannt, und die Programm-Datei hat die normale Endung lpr

[siro]

Achso, Projekt speichern unter benutzen. Okay.
Jo, dann bleibt das auch bei .lpr

Ich hab mich schon gewundert woher Lazarus nun weis welche Datei das sein soll,
also hab ich grad mal in der *.lpi Datei nachgesehen.
Dort ist es eingetragen bzw. da wird so ziemlich alles eingetragen.
Dies ist also die "lebenswichtige Datei" für das Projekt.

Ich muss ehrlicherweise zugeben, ich habe mich bisher nie darum gekümmert wie die Dateien heissen usw.
Alle Projekte hießen bis zuletzt Projekt1 und die .exe wurde erst nach Fertigstellung umbenannt.
Das war schon seit Delphi 3 im Jahr 1999 bei mir so.....Da gabs dann halt Unit1..Unit10

Auf jeden Fall vielen Dank Dir auch nochmal für die Informationen.

Siro

[wp_xyz]

Dies ist also die "lebenswichtige Datei" für das Projekt.

Genau, die lpi-Datei ist DIE Projekt-Datei. Allerdings kannst du das Projekt auch über die lpr-Datei öffnen (oder die umbenannte pas-Datei, sofern im Kopf das Schlüsselwort "program" steht). Das funktioniert auch, wenn die lpi-Datei verloren gegangen ist; allerdings musst du alle Angaben wieder neu aufbauen: also welcher Projekt-Typ das ist, welche Packages zum Projekt gehören und welche Dateien, welche Compiler- und sonstigen Einstellungen gelten sollen.