Unit-übergreifende Sichtbarkeit von {$Define …} - geht das?

[Sinspin]

Zitat:

Zitat von dummzeuch (Beitrag 1524901)

Zitat:

Zitat von Sinspin (Beitrag 1524900)

Eine Unit hat einen Initialization Abschnitt.
Du könntest damit erreichen das sich jede Unit in eine globale Liste einträgt.
Später, nachdem alle Units geladen sind, kannst du dann in der Liste nachsehen wer alles da ist.

Es gibt diese globale Liste bereits. Man kann damit herausfinden, ob eine Unit in ein Executable eingebunden ist oder nicht. Falls es das ist, was der OP erreichen möchte, hier ist Code dafür auf Stack Overflow (als Antwort auf eine Frage, die ich damals gestellt hatte).

Wieder was gelernt :thumb:
Mir ist schon vor langer Zeit beim durchsuchen von meinen, mit Delphi erzeugten, Binaries aufgefallen das da die ganzen Unit Namen drinne stehen. Einen Sinn habe ich darin nie gesehen.
Ich verwende die Initialization Abschnitte auch nicht zum sammeln von Unit Namen, wozu auch ;-). Sondern zum registrieren von Funktionen oder Klassen für automatische Konverter/etc.

[himitsu]

Jupp, diese Liste wird benutzt, um beim Start alle Initialization und am Ende alle Finalization zu durchlaufen.
Aber dort stehen nicht ALLE Units drin, vor allem nicht, wenn sie weder Initialization/Finalization, Class-Constructor/Destructor oder globale Variablen haben, weil dann ist es ja nicht nötig was zu machen.

Auch in den Ressourcen der EXE/DLL findet sich was, wo die Units aufgelistet werden.

Dann die Debuginfos als PE-Section.

Oder, wie schon gesagt, über TRTTI danach suchen.

[jaenicke]

Zitat:

Zitat von Andreas13 (Beitrag 1524907)

Habe gerade überprüft: Lediglich

Delphi-Quellcode:

MaxX

verursacht bei mir Probleme, weil dieser Bezeichner bereits in einer von mir anstelle von System.Math.pas benutzten Mathematik-Bibliothek verwendet wird.

Entweder du schreibst den Unitnamen davor oder du tauschst die Reihenfolge der Units in der uses-Klausel aus, damit der andere gefunden wird.

[dummzeuch]

Zitat:

Zitat von Sinspin (Beitrag 1524912)

sammeln von Unit Namen, wozu auch ;-).

Z.B. um im (generischen) About-Dialog die passenden Credits zu den verwendeten Bibliotheken anzuzeigen. Dazu ist das echt praktisch.

[himitsu]

Du baust also extra einen Code, der speziell nach dieser Unit sucht (oder Irgendeiner, die zufällig gleich heißt, aber was ganz Anderes ist),
um mit dieser Info dann was zu machen.

Warum dann nicht diese Info direkt reinschreiben?


Wenn, dann wäre es besser, wenn der Entwickler eine standardisierte Credits-Ressource bei legt, oder z.B. ein standardisiertes Credits-Attribut an seine Unit/Klasse/Sonstwas hängt, die man dann leicht finden könnte.

[Andreas13]

Zitat:

Zitat von jaenicke (Beitrag 1524916)

Entweder du schreibst den Unitnamen davor oder du tauschst die Reihenfolge der Units in der uses-Klausel aus, damit der andere gefunden wird.

Danke Sebastian, den Namenskonflikt habe ich durch qualifizierte Bezeichner bereinigt. :-D

[arcticwolf]

Zitat:

Zitat von Andreas13 (Beitrag 1524905)

Hallo Wolfgang,
danke für den Hinweis. Leider funktionier es bei mir noch nicht ganz korrekt. Im Anhang ist ein kleines Demo dazu.

Delphi-Quellcode:

PrintVektor(..)

ist eine "alte" (= bestehende) Routine, die

Delphi-Quellcode:

System.WriteLn(..)

verwendet.
Auch wenn ich

Delphi-Quellcode:

Console.Modes.UseAlternateWriteProc := False;

einstelle, wird der lange Output von

Delphi-Quellcode:

PrintVektor(..)

gekappt, weil

Delphi-Quellcode:

System.WriteLn(..)

nicht in

Delphi-Quellcode:

Console. WriteLnConsole(..)

umgeleitet wird, was ich mit meiner ursprünglichen Idee mit der "Zwischen-Unit" realisieren wollte.

Hallo Andreas,

Du denkst da ein bisschen kompliziert, eine ganze Unit brauchst Du dafür nicht ;-).

Vorab mal ein paar Fragen/Hinweise:
- Brauchst Du wirklich eine Zeilenlänge von 1.200 Zeichen und 15.000 Zeilen? -> Console.Buffer(10*120,10*1500, True); :?
- Du solltest beim Start immer die Größe des Konsolenfensters also den sichtbaren Bereich festlegen, z.B. auf 120 x 50 mit Console.Window(120,50). Sonst nimmt Windows einen Wert aus der Registry und der kann wenn deine Anwendung mal auf einem anderen Rechner läuft ein ganz anderer sein.
- In der Funktion "PrintVektor" verwendest Du System.Writeln, für die Ausgabe der Zeilen Crt.WritelnConsole. Wie ich im anderen Beitrag geschrieben habe, geht dieser Mix nicht.

Zitat:

Für die Ausgabe sollte/muss "WriteConsole" und/oder "WritelnConsole" verwendet werden, weil die normalen Ausgaben (Write/Writeln) auf feste Fenstergrößen abgestimmt sind

Wenn Du also diesen Ansatz (Vergrößerung des Puffers) verfolgen möchtest, dann leite doch einfach "System.Write & System.Writeln" direkt auf die Crt.WriteConsole um.

1. Eigene Funktion erstellen

Delphi-Quellcode:

Function  CrtWriteAlternateConsole(var t: TTextRec; s: UnicodeString) : Pointer;
begin
  WriteConsole(s);
  Result := @t;
end;

2. System.AlternateWriteUnicodeStringProc auf deine Funktion umleiten

Delphi-Quellcode:

AlternateWriteUnicodeStringProc := @CrtWriteAlternateConsole;

Fertig ist der Zauber. Dann ist es auch egal ob du Writeln oder WritelnConsole verwendest, abgesehen davon, dass der direkte Aufruf von WritelnConsole natürlich schneller ist als der Umweg über System.Writeln.

Ja OK, hört sich jetzt trivial an, ist es auch, zumindest für Dich. Die Arbeit im Hintergrund übernimmt dann automatisch meine "Console Library" 8-).

Das Ganze sieht dann in etwa so aus:

Delphi-Quellcode:

      AlternateWriteUnicodeStringProc := @CrtWriteAlternateConsole;

      Textcolor(Yellow);
      TextBackground(Blue);
      Console.Font.SetDefault;
      Console.Window(120,50);

      EnlageBufferSize;

      FillVektor(Vektor, 2);
      PrintVektor(Vektor, 'Vektor');

      For Zeile:= 1 To 200 Do
      Begin
        WriteLnConsole('Zeile[' + Zeile.ToString.PadLeft(3) + ']');
      End;
      Console.ReadkeyScroll(Key);

Das ist natürlich eine verkürzte Darstellung aber ich denke Du bekommst das hin.

Disclaimer: Das mit dem vergrößertem Puffer und WriteConsole ist von mir weder getestet noch im produktivem Einsatz gewesen. Das war/ist nur eine Idee von mir wie du ein Problem lösen könntest. Ich würde mich jedoch über Berichte freuen, ob das stabil läuft oder ob es Probleme gibt. Gerne auch per PM oder E-Mail (findest Du auf GitHub).

[Andreas13]

Vielen herzlichen Dank für Deine & Eure Unterstützung & Erläuterungen! :thumb: :thumb: :thumb:
"Kaum macht man es richtig, schon klappt es." :-D

Es tut mir leid, daß ich Eure Zeit mit meinem Kinderkram verplempere... :oops:

[dummzeuch]

Zitat:

Zitat von himitsu (Beitrag 1524937)

Du baust also extra einen Code, der speziell nach dieser Unit sucht (oder Irgendeiner, die zufällig gleich heißt, aber was ganz Anderes ist),
um mit dieser Info dann was zu machen.

Warum dann nicht diese Info direkt reinschreiben?

Wenn, dann wäre es besser, wenn der Entwickler eine standardisierte Credits-Ressource bei legt, oder z.B. ein standardisiertes Credits-Attribut an seine Unit/Klasse/Sonstwas hängt, die man dann leicht finden könnte.

Ich vermute, zumindest der letze Absatz bezog sich auf mich?

(Hint: Ein Quote hätte hier Klarheit geschaffen.)

Da die Entwickler diese Ressource nicht zur Verfügung stellen und ich nicht an deren Code rumfummeln will, war die Suche nach einer Unit, die beim Einbinden einer Bibliothek immer vorhanden ist, die einfachste Lösung. Und da die meisten Bibliotheken ein individuelles Prefix im Unit-Namen verwenden, ist das auch ziemlich eindeutig.

[himitsu]

Das bezog sich eigentlich auf "alle" Entwickler von Komponenten :)


Und wie schon erwähnt, kannst'e bei vielen Komponenten auch nach einer derer Ressourcen suchen.