Dateien umbennen - welches Namensformat?

[SneakyBagels]

Natürlich kann man Verzeichnisse beim Speichern anlegen.
Aber man kann Units nicht einmal in Verzeichnisse verschieben wenn man die Projektverwaltung nutzt. Neue Verzeichnisse OHNE eine Unit zu erstellen funktioniert auch nicht.

Zitat:

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

Bei einer Pro-Version und bei diesen Preisen ist das inakzeptabel bei den heutigen Möglichkeiten.

Vielleicht gesellt sich MEissing ja auch dazu.

[Rollo62]

Zitat:

Zitat von Rollo62:
So mit den Verzeichnissen würde ich das auch machen, wenn Delphi die Verzeichnisse akzeptieren würde.
Warum sollte es nicht? Funktioniert hier problemlos.

Was ich meine das in den Units uses keine Verzeichnisse angegeben werden können.
Das geht nur in der DPR Datei.

Delphi-Quellcode:

uses
    System.SysUtils   // OK
  , My.Special.Stuff  // OK
  , \My\Special\Stuff // Das geht leider nicht
  , D:\Lib\\My\Special\Stuff // Das geht leider auch nicht
  ;

[himitsu]

Nein, das geht natürlich nicht.
Egal ob mit ohne ohne Punkt, man gibt da immer nur eine Datei ohne Dateiendung und Pfade an.
Der Ort der Datei wird über die Suchpfade bestimmt/gefunden.

Ausnahme: Die Uses-Klausel in der Projektdatei (DPR), was auch der Dateiliste in der Projektverwaltung entspricht.

Delphi-Quellcode:

uses 
  Stuff in 'D:\Lib\My\Special\Stuff.pas';

Und wenn nachfolgend in irgendeiner Unit ebenfalls ein "Stuff" in den Uses steht, dann wird jene verwendet.

[jaenicke]

Zitat:

Zitat von Rollo62 (Beitrag 1376065)

Was ich meine das in den Units uses keine Verzeichnisse angegeben werden können.
Das geht nur in der DPR Datei.

Und das aus guten Gründen...
Sonst bindet man vielleicht eine gleichnamige Unit von der falschen Stelle ein.
Außerdem hat das rein gar nichts mit der Funktionalität zu tun. Die Organisation der Quelltextdateien ist Sache des Gesamtprojekts.

Kurz:
Das "Feature" wäre eine Katastrophe...

Wenn man das braucht, liegen die Probleme wohl eher beim Programmierer selbst...

[himitsu]

Unitnamen sind Eindeutig.
Also innerhalb einer kompletten EXE, DLL oder BPL existiert nur Eine mit diesem Namen.

Was soll denn passieren, wenn im Uses der UnitA xyz\UnitZ und in UnitB abc\UnitZ steht? Das ginge garnicht und müsste im Compiler knallen.
Oder schlimmer noch, in UnitC steht nur UnitZ ... selbst wenn die Unit mehrmals vorkommen darf, aus welchem Verzeichnis kommt dann diese UnitZ?

Es mag manchmal verwirrend sein, für uns Menschen, aber dennoch ist es immer eindeutig, wo eine Unit her kommt.
Entweder explizit im Projekt angegeben, aus dem selben Verzeichnis wie die übergeordnete Datei (worin das USES steht) oder im ersten Verzeichnis der Suchpfade, wo diese Unit gefunden wird.

[Rollo62]

Jaja schon gut.
Ich hätte das nur gerne wegen der Sortierung in unterverzeuchnissen.
Hab mich an die punktnotation ja schon lange gewöhnt

[himitsu]

Meine Units haben fast Alle xxx.yyy.zzz bzw. xxx.yyy.zzz.********
und das ist dann nochmal nach Projekten ala xxx oder xxx.yyy in gleichnamigen Unteverzeichnichnissen gruppiert.

Erstmal damit nich alles in einem Verzeichnis liegt und dann kann so auch jedes "Projekt" einzeln in die Versionskontrolle.

[Rollo62]

Dann muss man das aber im Search-Pfad abbilden, das habe ich auch lange so gemacht.
Mittlerweile werfe ich dann liefer vieles in ein großes Verzeichnis, und muss nicht
ständig die Pfade abbilden.

Meiner Meinung nach könnten die Uses um relative Pfade ergänzt werden, (am Besten so mit %(MYLIB) ),
um diese feste Abbildung in der Library in den Units abzubilden.
Wenn der gesamte Pfad dann als Unit-Namespace gilt gibt es auch keine Name-clashes.

Man darf ja noch träumen :stupid:

Rollo

[jaenicke]

Zitat:

Zitat von Rollo62 (Beitrag 1376170)

Dann muss man das aber im Search-Pfad abbilden, das habe ich auch lange so gemacht.

Package über die gemeinsamen Units, das in ein bestimmtes Bibliotheksverzeichnis kompiliert. Dieses kommt dann in den Bibliothekspfad.
Damit der Debugger auch die Quelltexte findet, müssen diese auch in den Suchpfad, das stimmt.

Aber wenn man eine Installationsanleitung pflegt, in der diese Verzeichnisse schon drin stehen, muss man diese nur für eine neue Delphiversion dort heraus kopieren... eine Sache von 1 Minute so alles einzustellen.

[Rollo62]

Zitat:

eine Sache von 1 Minute so alles einzustellen.

Ich habe früher immer Alles über Tools\Delphi Serachpfade abgebildet, dies wurden dann
bei verschiedenen 3rd Party Komponenten schnell vollgemüllt und unübersichtlich.

Im Moment bilde ich die Pfade über die lokalen Projektoptionen ab. also für jedes Projekt separat,
auch wenn es u.U. immer dasselbe ist.
Ich finde halt das jedes Projekt seine Pfade selbst definieren soll, damit is bei Wechsel von einer zur nächsten Version nicht immer diese "Pfadpflege" geben muss.
Das funktioniert in der Praxis aber nur weil ich mittlerweile mehr FMX und weniger (keine) externe 3rd Party Komponenten einsetze.
Ich habe mir dafür einfach eine Texdatei mit den minimalen Pfaden gemacht, und kann mit CopyPaste deie Standardpfade reinwerfen.
Das geht schnell, ja, ist trotzdem nervig.
Insbesondere Libraries die Strukturen aud mehrerem Unterverzeichnissen haben;
\Core\
\Base\
\Components\
etc.

Ich ertappe mich da immer wieder das bei Benutzung einer "exotischen" Komponente dan auch wieder ein Verzeichnis ergänzt werden muss.
Sehr sehr nervig ... (vielleicht sind meine Nerven auch bereits etwas überstrapaziert :-) )

Da würde ich halt gerne nur ein Root-Verzeichnis angeben, und alle Unterstrukturen sollten dann in den Units verwaltet und abgebildet sein.

Mit Unit-Packages hatte ich früher auch standardmäßig gearbeitet, aber die bilden eben die Unterverzeichnisse
auch nicht ab.
Statt Package lasse ich lieber ale Units neu kompilieren, das geht bei mir schnell genug und ich kann sicher sein das Alle DCU's aktuell sind.

Vielleicht ist mein Ansatz mittlerweile "Back to the Roots", besonders wenn ich sehe wie in anderen Umgebungen munter und sehr erfolgreich auf der Kommandozeile gearbeitet wird.
Da denke ich das zuviel IDE-Magic u.U. nicht unbedingt von Vorteil ist, und möchte Alles im Code abbilden :stupid:

Rollo

[himitsu]

Zitat:

Zitat von Rollo62 (Beitrag 1376263)

Ich habe früher immer Alles über Tools\Delphi Serachpfade abgebildet, dies wurden dann
bei verschiedenen 3rd Party Komponenten schnell vollgemüllt und unübersichtlich.

Vorallem wenn ein "Tool" mehrere Suchpfade hat, dann Diese in eine eigene Variable und dann nur die Variable in den Such-/Bibliothekspfad, als

Delphi-Quellcode:

%ToolPfad%

oder

Delphi-Quellcode:

$(ToolPfad)

.
Tools > Optione... > Umgebungsoptionen > Umgebungsvariable

Ob diese Variable dann in Delphi (neuer Name in "Vom Anwender überschrieben" oder in Windows "Umgebungsvariablen für dieses Konto" oder gar in "Systemvariablen" rein kommen, das hängt davon ab, ob man diese Variablen auch in externen Programmen nutzen will.
Leider wurden in

Delphi-Quellcode:

\bin\rsvars.bat

diese zusätzlichen Variablen vergessen.

[Rollo62]

Hallo Himitzu,

dankesehr für den Tipp
Das man in Tools > Optione... > Umgebungsoptionen > Umgebungsvariable auch mehrere Pfade unten einen Bezeichner angeben kann habe ich nocht nicht probiert.
Ist einen Versuch wert.

Kann man auch diese Environment Konfiguration bequem speicern:
$(ToolPfad1)=...
$(ToolPfad2)=...
$(ToolPfad2)=...
...
$(ToolPfadn)=...

wenn man von einer Version zur nächsten geht ?
Genau diese Art von Konfigurationsorgien möchte ich Vermeiden.

So wie ich es sehe muss jeder Environment Pfat einzeln bearbeitet werden, oder wömöglich gibt es tief in RegEdit oder sonstwo eine Möglichkeit das als .reg oder anders zu speichern.

Rollo

[himitsu]

Code:

ToolA=Pfad1;Pfad2;Pfad3
ToolB=Pfad
Suchpfad=...;$(ToolA);$(ToolB);$(ToolC)

Das Selbe kann man auch bei der PATH-Variable von Windows machen,
aber man muß eventuell aufpassen, dass die Untervariablen z.B. alphabetisch sortiert vor der Zielvariable stehen.

Vorteil ist auch, dass man so die großen Variablen leichter bearbeiten (vorallem aufräumen/löschen) kann.
Und es lässt sich leichter prüfen, ob etwas enthalten ist, z.B. in einem Setup, denn "enthält $(xyz)" ist einfacher, als "freidefinierbare" Pfade zu suchen, wenn man keine "festen" Installationspfade hat.
Und speziell bei einem Update gibt es so weniger Probleme, da nur die eigenen Variablen komplett angepasst werden müssen, anstatt die Pfade irgendeiner alten Version raussuchen und in der großen Suchpfadvariable anpassen zu müssen.

Nimm mal sowas wie DevExpress, wo im Suchpfad zwei Millionen Pfade auftauchen, da wäre es toll, wenn die auch sowas machen würden.