Dateien umbennen - welches Namensformat?

[SneakyBagels]

Ich möchte mich dieses Wochenende gerne daran begeben, die Units meines Projekts ordentlich umzubenennen.
Ich habe noch einige Leichen im Keller.

Meine Klassen werden alle ungefähr so heißen.. TStringUtils, TSonstwasUtils usw.
Wie würde ich aber die Units benennen, sodass sie am besten in der Unitliste alle zusammenhängend dargestellt werden (weil das manuelle Sortieren ja noch immer nicht richtig klappt!).

Ich dachte an etwas wie Utils.String. Aber ist das wirklich so clever denn der Klassenname wäre ja genau umgekehrt.

Meine Formulare nenne ich übrigens alle frmIrgendeineTreffendeBezeichnung. Wäre hier dann vielleicht auch Forms.IrgendeineTreffendeBezeichnung angebracht?

[nahpets]

eventuell einfach und banal sowas?

TStringUtils -> Unit: UStringUtils
TSonstwasUtils -> Unit: USonstwasUtils

[Bernhard Geyer]

Wenn man keine Antiken Delphi-Versionen unterstützen muss dann mit Namespace.

TStringUtils -> Unit: SneakyBagels.StringUtils

Damit geht man der Gefahr aus dem Weg Kollisionen mit Unitnamen neueren Delphis oder 3th-Party-Komponenten zu bekommen.

[SneakyBagels]

Zitat:

TStringUtils -> Unit: SneakyBagels.StringUtils

Ist das tatsächlich ein gebräuchliches Format?
Was könnte man denn noch außer den Benutzernamen nehmen? Der Programmname wäre m.E. nicht so pralle :|
Vielleicht die ersten beiden Initialen meines Programmnamens?

[Der schöne Günther]

Zitat:

Zitat von SneakyBagels (Beitrag 1374063)

Ich dachte an etwas wie Utils.String. Aber ist das wirklich so clever denn der Klassenname wäre ja genau umgekehrt.

Genau das ist eigentlich Usus.

https://docs.oracle.com/javase/tutor...amingpkgs.html

https://msdn.microsoft.com/en-us/lib...18(vs.71).aspx


Du bist niemandem einen Namen schuldig. Wichtig ist es dass es konsequent durchgezogen wird und der Namen dir erlaubt deinen Kram vernünftig zu finden.

[SneakyBagels]

Zitat:

Du bist niemandem einen Namen schuldig. Wichtig ist es dass es konsequent durchgezogen wird und der Namen dir erlaubt deinen Kram vernünftig zu finden.

Das stimmt auch wieder. Problem ist bei meinen Units mit thematisch sortierten Funktionen drin, dass die Unit-Namen kein bisschen mit den Klassennamen übereinstimmen.
Daher dachte ich an eine ordentliche Umbenennung.

[Uwe Raabe]

Zitat:

Zitat von SneakyBagels (Beitrag 1374067)

Was könnte man denn noch außer den Benutzernamen nehmen? Der Programmname wäre m.E. nicht so pralle :|

Wieso nicht? In einigen Projekten verwende ich das genau für die projektspezifischen Units. Das ist insbesondere hilfreich, wenn mehrere Projekte zu einer Projektgruppe gehören, die UNits mit ähnlicher Funktionalität haben, aber eben nicht gleich sind.

MyProject1.Utilities.pas, MyProject2.Utilities.pas,...

[SneakyBagels]

Eine Frage bleibt noch... wie würde ich denn die ganzen Utils-Units ordentlich und nacheinander sortiert bekommen?
<Programmname>.StringUtils.pas, <Programmname>.DateUtils.pas da sist ja OK. Aber alphabetisch sortiert werden kann das schlecht =/
<Programmname>.Utils.Strings.pas ist nicht so toll oder?

[Der schöne Günther]

Zitat:

Zitat von SneakyBagels (Beitrag 1374071)

<Programmname>.Utils.Strings.pas ist nicht so toll oder?

Für mich wäre das ganz nach meinem Geschmack ;-)

Wenn es sich lohnt, warum nicht? In unserer Lieblings-Entwicklungsumgebung ist das ja auch...

Code:

System.Classes.pas

System.Generics.Collections.pas
System.Generics.Defaults.pas

System.JSON.pas
System.JSON.Writers.pas
System.JSON.Types.pas

[himitsu]

Zitat:

Zitat von SneakyBagels (Beitrag 1374071)

<Programmname>.Utils.Strings.pas

Bei mir haben Units auch mindestens 2 bis 3 Ebenen.

MeinKürzel.DieFunktion.pas
MeinKürzel.EineGruppe.DieFunktion.pas

"MeinKürzel" für Komponenten/GemeinsameUnits und "ProjektName" für das jeweilige Projekt.


Man muß auch nicht unbedingt name.space verwenden, denn unser_score oder CamelCase ist auch weit verbreitet, aber so passt es sich in die Unitnamen des Delphi ein und man kann auch mal mit DefaultNamespaces arbeiten.
VCL.MeinKürzel.EineGruppe.DieFunktion.pas
FMX.MeinKürzel.EineGruppe.DieFunktion.pas

Im Programm nimmt man dann nur noch MeinKürzel.EineGruppe.DieFunktion und Delphi nimmt die Unit des verwendeten GUI-Systems.

Wobei es mir eigentlich besser gefallen würde, wenn es so hieße :stupid:
MeinKürzel.EineGruppe.DieFunktion.VCL.pas
MeinKürzel.EineGruppe.DieFunktion.FMX.pas

[SneakyBagels]

Dann werde ich mich heute Abend mal daran machen und alles vernünftig umbenennen. Habe eben schon ein paar Units so angepasst, dass ich folgendes Konstrukt im Kopf habe:

Delphi-Quellcode:

unit ab.Utils.Strings;

interface

uses ... ;

// ------------------------------------------
type
 TStringUtils = record
 private
  //
 public
  class procedure test; static;
 end;
// ------------------------------------------

implementation

class procedure TStringUtils.test;
begin
end;

end.

Alles zwischen // ------ baue ich grundsätzlich in alle meine Units ein.

Ich würde es sehr begrüßen, wenn die IDE ein bisschen moderner wäre. Man siehe sich nur den Solution-Explorer in VisualStudio an.
Bei Delphi funktioniert ja nicht einmal Unit markieren => F2

MeinKürzel.EineGruppe.DieFunktion.FMX.pas
Wenn ich STRG gedrückt halte, muss ich dann zu MeinKürzel oder EineGruppe springen können? Denn das hier ist ja nur eine einzige Datei und man könnte in diesem Falle nur zu FMX springen.

[Luckie]

Ich setze immer noch mein Namenskürzel davor: MpUSysTools.pas, wenn es sich nicht um Projekt spezifische Units handelt. Ansonsten heißt die Unit wie die darin enthaltene Klasse nur mit einem "U" davor. Units mit Formularen beginnen mit "frmBlablaDialog.pas" und die Unit des Hauptformulares heißt einfach Main.pas.

[Der schöne Günther]

Vielleicht habe ich eine Leseschwäche, vielleicht bin ich verweichlicht, aber vor allem im ersten Fall sehe ich nur Suchbabenstalat und brauche drei Anläufe um zu entziffern was gemeint ist.

[Luckie]

Oft lasse ich das U dann auch weg: MpSysTools.pas.

[p80286]

Bei mir sieht es so aus:
MyProg.DPR
MyProg_.PAS {Main}
MyProgDM.pas {DataModule}
MyProgCSV.pas {Constanten,Typen,Variablen}
MyProgINI.pas {Initialisierung,Registry,IniFiles}

.....
AsciiDelim.Pas {csv}
Toolbox.Pas {utilities}

Gruß
K-H

[SneakyBagels]

Eine Art "Toolbox" hatte ich auch. Aber es gibt mittlerweile so viel Code dort drin, dass ich diese Datei aufteilen muss. So sind aktuell schon aus einer großen Datei etwa 15 kleine, thematisch sortiert geworden.

[himitsu]

Müsste es nicht MyProgCTV und MyProgIRI heißen? :angle2:

Bei CSV und INI dachte ich erst an was ganz Anderes.

[SneakyBagels]

Das ist aber ein schönes Beispiel, dass es wohl keine Norm gibt und jeder sein eigenes System hat.

[SneakyBagels]

Hier noch eine weitere Möglichkeit von Herr Jaenike

Zitat:

// EDIT:
Nebenbei, falls die Unitnamen echt sind:
Unterstriche in Unitnamen und Bezeichnern sind in Delphi unüblich. In Delphi ist CamelCase üblich und für Unitnamen auch Punkte. (Empfinde ich auch als deutlich besser lesbar.)
Bei uns würden die Units z.B. heißen (wenn es allgemeine Units für mehrere Projekte sind, daher Common):
Common.Utils.Logging.pas, Common.Types.Logging.pas, ... (Im Unterverzeichnis common\utils bzw. common\types)
Und so allgemeine Namen wie _globals oder so würde es bei uns nicht geben, da das nichts über die Funktion aussagt. Die Klasse hieße bei uns dann auch z.B. TLogging und wäre die einzige in der Unit.
Auf die Weise werden auch die Units nicht so groß und übersichtlich und man findet auch direkt die Units zu den Klassen.

Hierzu eine Frage:
Common steht hier wohl vermutlich dafür, dass die Unit nur in diesem einen Project verwendet wird.
Wird für eine Unit, die in mehreren Projekten verwendet wird, demnach Shared verwendet?

Angenommen ich habe eine Unit Utils.Logging.pas - was käme dann da rein?
Und was in Types.Logging.pas?

Sehe ich das richtig, dass in erste Unit der Log-Code ansich kommt und in letzte zum Beispiel Records, Classes, Enums?
Aktuell habe ich es so, dass ich alle meine Enums in einer einzigen Unit drin habe.

[jaenicke]

Zitat:

Zitat von SneakyBagels (Beitrag 1375841)

Common steht hier wohl vermutlich dafür, dass die Unit nur in diesem einen Project verwendet wird.

Wir haben diese Struktur:
Projekt.Kategorie.(Untergruppe.)Unitname.pas
bzw. für Interfaces:
Projekt.Interfaces.Kategorie.(Untergruppe.)Unitnam e.pas

Auf die Weise werden die Namen nicht zu lang, sind aber dennoch eindeutig. Projekte sind bei uns so etwas wie Server, Frontend, Backend usw. sowie bei gemeinsamen Units Common. Kategorien sind z.B. Network, Encryption, Hardware, ...
Untergruppen sind optional und kaum benutzt (die Unitnamen werden damit halt schon recht lang).

Die Unit heißt immer genauso wie das Interface oder die Klasse, die sich darin hauptsächlich befindet. Es sollte auch nichts zusätzlich drin sein, das nicht direkt dazu gehört.

Und jeder Punkt ist auf der Festplatte ein Pfadtrennzeichen, sprich es liegen auch nicht so viele Units in einem Verzeichnis, man findet die Units aber dennoch leicht und für Skriptzugriffe auch automatisiert.

Beispiel:
IPrinter wäre in Common.Interfaces.Hardware.Printer.pas definiert, TEpsonPrinter z.B. in Common.Hardware.EpsonPrinter.pas.

Mit Tools wie den CnWizards, die die Syntaxergänzung erweitern, so dass die Printer-Unit auch mit der Eingabe "ComIntHarPri" (kleingeschrieben, nur zur Verdeutlichung) gefunden wird, sind natürlich sehr hilfreich um weniger tippen zu müssen.

Zitat:

Zitat von SneakyBagels (Beitrag 1375841)

Sehe ich das richtig, dass in erste Unit der Log-Code ansich kommt und in letzte zum Beispiel Records, Classes, Enums?
Aktuell habe ich es so, dass ich alle meine Enums in einer einzigen Unit drin habe.

Wir machen das aus mehreren Gründen nicht so.
Der wichtigste ist, dass man so Funktionalität auf mehrere Units verteilt und so bei Änderungen an größeren Units etwas ändert, an denen dann öfter Änderungen für verschiedene Teile der Anwendungen passieren. Das macht es nicht einfacher Änderungen nachzuverfolgen und zu mergen.

Gemeinsam genutzte Typen wie TColor in System.UITypes deklarieren wir natürlich auch zentral.

Dazu kommt, dass man nicht nur die Unit in die uses kleben muss, die die Funktionalität enthält, sondern zusätzlich noch z.B. eine für Enums usw.
Sind die Typdefinitionen direkt in der Unit mit dem Interface, sind diese bereits direkt bekannt. Man muss also nicht erst suchen wo der Rest definiert ist. Das macht die Verwendung deutlich einfacher.

[SneakyBagels]

Hierzu eine abschließende Frage:

Utils.Logging.pas:
- enthält Funktionen und Prozeduren betreffend "Logging"
- Funktionen und Prozeduren von Utils.Logging können von anderen Units verwendet werden, indem man die Utils.Logging-Unit in weitere Units einbindet

Types.Logging.pas:
- enthält Record-s, Class-es, Enums etc, welche nur in Utils.Logging verwendet werden
- wird in Utils.Logging.pas eingebunden, sonst nirgendwo

Ist das richtig so von der Logik oder stelle ich mir gerade ein Bein und habe irgendetwas noch nicht verstanden?

Sinn soll es ja u.a. sein, dass man so wenig Abhängigkeiten zu anderen Units wie möglich hat nehme ich an?
Falls dem so ist, darf man denn dann überhaupt in Utils.Logging.pas weitere Units einbinden?
Angenommen ich habe eine Unit mit Variablen die programmweit verfügbar sein sollen und eine davon benötige ich in Utils.Loggins.pas.
Wie sähe das konkret aus?

Hier ist das, was ich bisher verstanden habe

Delphi-Quellcode:

unit Types.Logging;

interface

uses
 System.Classes, System.SysUtils, ...;

type
 TBeispielEnum = (test, blub);

implementation

end.

/////////////////////////////////////////////////

unit Utils.Logging;

interface

uses
 Types.Logging, // darf Types.Logging verwenden für eventuelle spätere Zugriffe auf TBeispielEnum (?)

 System.Classes, System.SysUtils, ...;

type
 TLogging= class
 private
  //
 public
  class function Test(iiiii: Integer): Integer; static;
 end;

implementation

// uses .... ; // <= andere Units des Programms einbinden, ist das erlaubt?

class function TLogging.Test(iiiii: Integer): Integer;
begin
 Result := iiiii + 1;
end;

end.

////////////////////////////////////////

showmessage( IntToStr( TLogging.Test(1) ) );

P.S.: der Code würde -50 von 100 Punkten erhalten, wenn es um den Sinn und die Funktionalität ginge.

[himitsu]

Ich würde es ja andersrum machen.

Logging.Utils.pas
Logging.Types.pas

Erstmal sind so die zusammengehörigen Dateien auch im Dateisystem zusammen
und bei Codevervollständigung und Unitsuche nach "Log", "Logging." usw. sieht man alles, was zum Logging gehört oder was sonst noch vorhanden ist.

Die Haupt-/Grundfunktionen, mit den Typen, Konstanten usw. lege ich auch zusammen in eine Unit
Optionale und zusätzliche Dinge konnen in andere Units.
Im einfachsten Fall muß dann auch nur eine Unit eingebunden werden.

Delphi-Quellcode:

ShowMessage(TLogging.Test(1).ToString);

[SneakyBagels]

Zitat:

Erstmal sind so die zusammengehörigen Dateien auch im Dateisystem zusammen (...) und bei Codevervollständigung und Unitsuche...

Das ist wohl ein Pluspunkt.

Zitat:

Die Haupt-/Grundfunktionen, mit den Typen, Konstanten usw. lege ich auch zusammen in eine Unit
Optionale und zusätzliche Dinge konnen in andere Units.

Das habe ich nicht ganz verstanden. Was konkret würdest du denn in Utils und was in Types packen?

Ich entschuldige mich für all die dummen Fragen. Aber wenn ich bald schon anfange alles umzubenennen und zu verbessern, dann richtig =)

[himitsu]

Delphi-Quellcode:

Logging.Consts.Internals.pas
Logging.Consts.pas
Logging.Types.Internals.pas
Logging.Types.pas
Logging.Interfaces.Internals.pas
Logging.Interfaces.pas
Logging.Classes.Internals.pas
Logging.Classes.pas
Logging.Utils.pas
Logging.Utils.Database.pas
Logging.Utils.Files.pas
...

uses Logging.Consts, Logging.Types, Logging.Interfaces, Logging.Classes, Logging.Utils, ...;

Delphi-Quellcode:

Logging.Internals.pas oder Logging.Base.Internals.pas  // wenn es viel Internes gibt, was nur die Loggingklassen/-funktionen, aber nicht der User nutzt
Logging.Base.pas
Logging.Utils.pas
Logging.Utils.Database.pas
Logging.Utils.Files.pas
...

uses Logging.Base, Logging.Utils, ...;

Wenn du deine Logging-Klasse verwenden willst, dann brauchst du in der Regel auch einige Typen/Enums und eventuell auch 'nen paar Konstanten.

[SneakyBagels]

Das sieht verdammt kompliziert aus. Jetzt sind wieder zwei neue dinge hinzugekommen: Base und Internals. Ich wüsste nicht einmal damit etwas anzufangen.
Ich glaube wenn dann bleibe ich bei

Zitat:

Logging.Utils.pas // Funktionen und Prozeduren
Logging.Types.pas // Konstanten, Variablen, Klassen, Records. Eventuell statt "Types" auch "Internals".

Eventuell, wenn es zuviel wird auch

Zitat:

Logging.Utils.NameUnterfunktion // Code, der in Funktionen in Utils ist, Utils auber aufblähen würde, könnte ich dann in NameUnterfunktion auslagern

Aber zur Frage:
dürfen die beiden oben genannten Units weitere Units in der Uses-Klausel stehen haben?

[himitsu]

Wie man seine Grund-Unit nennt, ist vom Prinzip ertmal egal ... da gibt es tausende mögliche Namen.

Zitat:

Zitat von SneakyBagels (Beitrag 1375897)

dürfen die beiden oben genannten Units weitere Units in der Uses-Klausel stehen haben?

Natürlich dürfen eingebundene Units in sich beliebig andere Units einbinden.
Nur nicht sich selbst, aber Kreisreferenzen/Kreuzreferenzen sind eh eine eigene unendliche Geschichte.

Aber es ist egal, ob Unit1 auch die Unit2 einbindet.
In deiner Unit hast du dennoch nur direkten Zugriff auf die Unitinhalte, die im Interface der bei dir eingebundenen Units drin sind.

Delphi-Quellcode:

// in Unit1.pas
uses Unit2, Unit3, Unit4;

// in deiner Unit
uses Unit1;

Nur Zugriff auf Unit1

Delphi-Quellcode:

// in Unit1.pas
uses Unit2, Unit3, Unit4;

// in deiner Unit
uses Unit1, Unit2;

Auch Zugriff auf Unit2.

Ich hab mir auch schonmal sowas wie Unit-Gruppen oder Unit-Makros gewünscht, oder wie man es sonst nennen will.
Also wich dann z.B. nur

Delphi-Quellcode:

uses Logging.AllUnits;

schreibe und irgendwo ist deffiniert, dass dieses ein "Alias" für

Delphi-Quellcode:

Logging.Consts, Logging.Types, Logging.Interfaces, Logging.Classes, Logging.Utils

ist.
Da könnte man sich dann Gruppen für KompletteVCLWeilIchkeineLustHabeTausendeUnitsEinze lnEinzubinden, DataSnapUnits, DevExpressUnits, FastReportUnits oder EurekalogUnits anlegen.
Aber das fänden Andere wieder total blöd und extremst sinnlos, siehe die aktuelle Dateigrößediskusion :stupid:

[SneakyBagels]

Zitat:

Natürlich dürfen eingebundene Units in sich beliebig andere Units einbinden.

Danke. Ich habe mir diese Frage nur gestellt, denn ich dachte immer die Units müssen sauber bleiben, sodass man sie locker flocking von Projekt A nach Projekt B mitnehmen kann.
Das ist bei mir aber schon nicht möglich denn meine Logging-Unit fragt Strings aus einer anderen Unit (Language, mehrsprachiges Programm) ab.
Ist aber glaube ich auch relativ unwichtig hier, denn ich habe eh nur ein Projekt in der Größenordnung.

[jaenicke]

Zitat:

Zitat von SneakyBagels (Beitrag 1375888)

Zitat:

Erstmal sind so die zusammengehörigen Dateien auch im Dateisystem zusammen (...) und bei Codevervollständigung und Unitsuche...

Das ist wohl ein Pluspunkt.

Deshalb stehen bei uns die Typen ja wie schon geschrieben in der gleichen Unit. So können wir thematisch gut gruppieren und man muss auch nur eine Unit einbinden. Sobald du das auf mehrere Units aufteilst, bleibt dir wie schon geschrieben nichts anderes übrig als beide Units einzubinden bei der Verwendung. Das macht es deutlich umständlicher.

Sprich eine Unit mit Interface und Typen dazu und eine zweite mit der Klasse, die das Interface implementiert.

Und bezüglich Einbindung anderer Units:
Da gilt nur die Regel bei uns, das gemeinsame Units auch wieder nur gemeinsame Units einbinden dürfen. Sprich keine Units aus bestimmten Projekten.

[SneakyBagels]

Zitat:

Sobald du das auf mehrere Units aufteilst, bleibt dir wie schon geschrieben nichts anderes übrig als beide Units einzubinden bei der Verwendung. Das macht es deutlich umständlicher.

Das stimmt natürlich auch.

Ich muss noch gut überlegen was ich mache.
Logging.Utils und Logging.Types wäre natürlich super denn dann wäre alles getrennt und man wüsste in der Unitliste sofort wo man dran ist.

[DevLinus]

Ich strukturiere meine Units so.

Code:

rootFolder // Darin alle Forms in der regel mit Allias un davor.
rootFolder/unMain.pas
rootFolder/unSettings.pas
...// Dann kommt ein Fragment ordner falls ich sie nutze.
rootFolder/Fragment
rootFolder/Fragment/Fragment.Header.pas
rootFolder/Fragment/Fragment.Footer.pas
...// Und genau so weiter mit Datamodels und Klassen die irgend einen zusammenhängenden Zweck haben.
rootFolder/Logger/Logger.Utils.pas
rootFolder/Logger/Logger.Typs.pas
....

Finde ich schön übersichtlich und bin ich von Java gewöhnt mit Packages.

[SneakyBagels]

Zitat:

rootFolder/Logger/Logger.Utils.pas
rootFolder/Logger/Logger.Typs.pas

Was packst du denn in Utils und was in Types?

[DevLinus]

Zitat:

Zitat von SneakyBagels (Beitrag 1375970)

Zitat:

rootFolder/Logger/Logger.Utils.pas
rootFolder/Logger/Logger.Typs.pas

Was packst du denn in Utils und was in Types?

Das gleiche wie du eigentlich :) Wobei bei einem Projekt hatte ich noch eine weitere Unit für Konstanten die ich auch außerhalb meiner Logger units verwendet habe.

[SneakyBagels]

Zitat:

Das gleiche wie du eigentlich

Aktuell habe ich dieses System ja noch nicht :P
Aber ich denke in Types würde ich Records, Classes, Enums reinpacken und in Utils Prozeduren und Funktionen.

Ich denke es läuft darauf hinaus, dass ich .Utils und .Types verwenden werde.
Das bedeutet viel Arbeit alles umzustellen.

[DevLinus]

Zitat:

Zitat von SneakyBagels (Beitrag 1375972)

Zitat:

Das gleiche wie du eigentlich

Aktuell habe ich dieses System ja noch nicht :P
Aber ich denke in Types würde ich Records, Classes, Enums reinpacken und in Utils Prozeduren und Funktionen.

Ich denke es läuft darauf hinaus, dass ich .Utils und .Types verwenden werde.
Das bedeutet viel Arbeit alles umzustellen.

Okay dann wie du es vor hast :)

[jaenicke]

Bei uns gibt es keine losen Funktionen...
Wenn, dann liegen die in der thematisch passenden Klasse als Klassenfunktion.
Eine Utils-Unit enthält bei uns z.B. die Common.Utils.StringTools.pas die Klasse TStringTools mit passenden Methoden.

[SneakyBagels]

Zitat:

Ich denke es läuft darauf hinaus, dass ich .Utils und .Types verwenden werde.

Hätte das wohl besser ausschreiben sollen.

Ich meine natürlich Klasse.Utils und Klasse.Types.
Eventuell noch Common oder der Projektname davor, mal gucken.

[Rollo62]

So mit den Verzeichnissen würde ich das auch machen, wenn Delphi die Verzeichnisse akzeptieren würde. Deshalb mache ich mehr im flachen Verzeichnis mit punkten getrennte unitnamen.

[jaenicke]

Zitat:

Zitat von Rollo62 (Beitrag 1376033)

So mit den Verzeichnissen würde ich das auch machen, wenn Delphi die Verzeichnisse akzeptieren würde.

Warum sollte es nicht? Funktioniert hier problemlos.

[SneakyBagels]

Zitat:

Warum sollte es nicht? Funktioniert hier problemlos.

Vielleicht meint er die Tatsache, dass man bis heute! keine Verzeichnisse über die Projektverwaltung anlegen kann, wie man es wunderbar in Visual Studio kann.

Allgemein ist die Projektverwaltung aus der Steinzeit. Ich würde mir wünschen, dass man hier Verzeichnisse erstellen kann, Units in Verzeichnisse verschieben kann usw.
Vielleicht wäre das mal was für Delphi DX15.9.

[hsg]

Beim Speichern einer Unit kann man doch ein Verzeichnis anlegen. Und dank "Speichern unter" kann man auch eine Unit quasi verschieben (obwohl man leider die Original-Datei leider händisch löschen muss):?:

Es wäre zwar ein "Nice to have", aber ich kann mit den Kompromissen durchaus leben.