Konsolenanwendung - crt.pas - Console Library

[himitsu]

GetStdHandle sollte so oder so gehen, denn ob die CMD oder das Terminal, die Daten-Pipe bleibt die Gleiche.
Nur dass sie seit einer Weile über die ConHost-EXEn behandelt werden
und es somit möglich ist hinten einen anderen Viewer anzuhängen oder vorne eine andere Datenquelle (Console, PowerShell, Python, eine Linux-Bash, sowie die Consolen vom MAC, Android, Azure, AWS usw.).


Wie gesagt, die alte API läuft parallel zu den 3 Consolen-Handle vom Windows, über einen eigenen Kanal. (weiß garnicht, ob Linux einen eigenen Error-Stream hat, aber da eh kaum Windows-Programme Diesen nutzen, ist er fast egal)
Im neuen Streaming werden Daten und Control-Befehle im selben Stream übertragen. Ähnlich wie ganz früher, mit den EscapeCodes.




Sobald beim Start die Console nicht verbunden war (z.B. bei einer VCL-Anwendung), oder wenn die Pipe umgeleitet wird, oder der "Viewer" diese ControlPipe nicht explizit abfragt, dann kann das nicht funktionieren.

Über AttachConsole/AllocConsole könnte man prüfen ob eine "Console" dran hängt, oder z.B. die Pipe in ein anderes Programm umgeleitet ist. (siehe mein alter FileSplitter, der prüfte, ob er aus der Console, bzw. einer Batch, oder z.B. aus dem Explorer, einem Link oder via ShellExecute/CreateProcess gestartet wurde)

[arcticwolf]

Zitat:

Zitat von KodeZwerg (Beitrag 1523871)

Ich verstehe.
Was für einen Prozess startet denn eine Konsolen Anwendung mit installierten Terminal?
Mit der klassischen Konsolen Anwendung hab ich "conhost.exe" unter meiner ProcessID.

Wenn ich das Programm als Terminal starte, dann habe ich in der Prozessliste eine "WindowsTerminal.exe", eine "conhost.exe" und die "Demo01_Minimal_Console_App.exe".
Wenn ich das Programm als Konsolenhost starte, dann habe ich in der Prozessliste eine "conhost.exe" und die "Demo01_Minimal_Console_App.exe".

[Andreas13]

Hallo Wolfgang,
vielen Dank für die Anpassung & Verbesserung Deiner Console Library an ältere Delphi-Versionen! :-D Nun lassen sich mit XE5 alle 9 Units der Bibliothek kompilieren. :thumb:
Allerdings läßt sich nur ein einziges der 8 Demo-Programme kompilieren: Demo01_Minimal_Console_App.dpr
Bei den übrigen kommt es zu etlichen Fehlermeldungen:

Delphi-Quellcode:

u. a. 
begin
  Result := (FTextAttr and COMMON_LVB_REVERSE_VIDEO) = COMMON_LVB_REVERSE_VIDEO;
end;

[dcc32 Fehler] Ply.Console.pas(951): E2003 Undeklarierter Bezeichner: 'COMMON_LVB_REVERSE_VIDEO'
… 
[dcc32 Fehler] Ply.Console.pas(963): E2003 Undeklarierter Bezeichner: 'COMMON_LVB_GRID_HORIZONTAL'
[dcc32 Fehler] Ply.Console.pas(981): E2003 Undeklarierter Bezeichner: 'COMMON_LVB_GRID_LVERTICAL'
[dcc32 Fehler] Ply.Console.pas(987): E2003 Undeklarierter Bezeichner: 'COMMON_LVB_UNDERSCORE'
[dcc32 Fehler] Ply.Console.pas(999): E2003 Undeklarierter Bezeichner: 'COMMON_LVB_GRID_RVERTICAL'

etc.

Weitere Fehlermeldungen habe ich im Anhang.

Vielleicht findest Du noch eine Lösung für XE5-Benutzer(innen)...

[arcticwolf]

Hallo Andreas,

bitte schau noch einmal ob sich Demo01 wirklich immer noch kompilieren lässt.

Ich würde vermuten, da hat sich bei Dir irgendwo im Quellcode ein oder mehrere Zeichen eingeschlichen, die da nicht sein sollten. Wenn sich Demo01 kompilieren lässt, warum sollte sich die Ply.Console.Pas (die bei Demo01 auch benötigt wird) dann bei Demo02 nicht mehr kompilieren lassen? :gruebel:

Wenn alles nicht hilft, mach bitte noch einmal einen neuen pull von GitHub.

[Andreas13]

Hallo Wolfgang,

Du hast recht: Auch Demo01_Minimal_Console_App.dpr läßt sich nicht kompilieren:

Delphi-Quellcode:

[dcc32 Fehler] Demo01_Minimal_Console_App.dpr(13): E2003 Undeklarierter Bezeichner: 'Console'
[dcc32 Fehler] Demo01_Minimal_Console_App.dpr(13): E2035 Nicht genügend wirkliche Parameter

Die erste Zeile

Delphi-Quellcode:

Console.Window(80,25);

verursacht die Probleme.

Versehentlich hatte ich am Nachmittag eine Kopie von Demo01_Minimal_Console_App.dpr von gestern kompiliert...:oops:

[arcticwolf]

Hallo Andreas,

irgendwie macht das keinen Sinn. Wenn Du sagst

Zitat:

Nun lassen sich mit XE5 alle 9 Units der Bibliothek kompilieren.

der Compiler aber dann die "Var Console" nicht findet, die in der Crt.pas in Zeile 78 deklariert ist, dann würde ich vermuten, dass bei Dir irgendwas mit den Pfaden nicht stimmt. Im Projekt ist der Suchpfad auf das Parent-Directory ".." eingestellt. Also oberhalb von \Demo. Wenn Du an den Pfaden nichts geändert hast, sollte er die (meine) crt.pas finden und damit auch die "Var Console". Räum doch bitte mal auf und lösche alles was nicht mit dem GitHub Repository kommt. Also vor allem die Verzeichnisse .\Demo\Win32\ und .\Demo\Win64\ um zu vermeiden, dass der Compiler da eine alte crt.dcu findet.

Oder der Compiler findet noch irgendeine andere crt.pas oder crt.dcu? Schau mal im globalen Suchpfad, siehe "Tools -> Optionen -> Delphi -> Bibliothek" o.ä. je nach Delphi-Version. Das würde erklären, warum der dann in der Unit Crt keine "Var Console" findet.

[Andreas13]

Hallo Wolfgang,
ich habe gerade die Lösung für mein Compiler-Problem gefunden: Bei mir gibt es noch eine andere Unit namens Crt.pas und diese Unit steht bei mir im Suchpfad und wird zuerst gefunden.

Weil ich die Directory-Struktur Deiner Console-Master Library nicht geändert habe, klappt es bei mir mit den Demos erst, wenn ich den Pfad für Dein Crt.pas wie folgt ändere:

Delphi-Quellcode:

...
uses
  Crt in '..\Crt.pas',
;
...

oder z.B. in Ply.Crt.pas umbenenne.

Tolle & nützliche Bibliothek! :thumb: :thumb:
Danke! :-D

[arcticwolf]

Hallo Andreas,

Zitat:

Tolle & nützliche Bibliothek! Danke!

Vielen Dank! :-D

Da war ich ja schon auf der richtigen Spur, dass da eine andere crt.pas im Spiel ist. Ich habe deinen Vorschlag

Zitat:

Delphi-Quellcode:

uses
  Crt in '..\Crt.pas',

in die Demos übernommen, damit andere Nutzer das Problem künftig nicht mehr haben, dass eine andere crt.pas zuerst gefunden wird. Ply.Crt.Pas habe ich mit Absicht nicht genommen, weil das den Aufwand deutlich erhöhen würde, wenn jemand ein altes Programm mit vielen Units hat, welche die crt.pas nutzen. So muss der Nutzer nur sicherstellen, dass meine crt.pas zuerst (oder besser als einzige) gefunden wird und nicht in jeder Unit das "uses crt" anpassen. Das hat/hatte auch historischen Eigennutzen. Ich hatte ganz lange Code im Einsatz, den ich parallel mit Borland Pascal 7.0 und Delphi (5.0 und später auch XE6) compilieren musste.
________________________

Ich habe heute das "Demo09_BuiltIn_Features" dem GitHub-Repository hinzugefügt. Das Demo soll die Funktionsweise einiger eingebauten Funktionen erklären, welche ohne extra Code automatisch zur Verfügung stehen sobald meine crt.pas bzw. Ply.Console.Extended.pas im Uses steht.

[Andreas13]

Vielen Dank, Wolfgang! :thumb: :-D

[Edit]
PS:
Im Demo09_BuiltIn_Features.dpr ist in Zeile 50 eine Inline-Deklaration

Delphi-Quellcode:

  Var FrameAttr := TTextAttr.Create(White, Red);

welche ältere Delphi-Versionen (auch XE5) noch nicht verstehen. Aber das läßt sich einfach umschreiben.

[Andreas13]

Hallo Wolfgang,
mir ist aufgefallen, daß tConsoleInfoEx zwei kleinere Speicherlecks (117 - 124 Bytes) verursacht. Die Fehlermeldung findest Du im Anhang.
Könntest Du bitte bei Gelegenheit nachschauen, woran das liegen kann?

Vielen Dank!