GUI mit Konsole

[nru]

Hallo Kollegen,

ich hab mal eine Frage zur Konsolen-Ausgabe einer "normalen" GUI-Anwendung. Geplant ist, eine GUI-Anwendung über Parameter im "Pseudo"-Consolen-Mode zu starten und ausführen zu lassen. Ähnlich wie z.B. RegEdit.exe oder 7z.exe. Ohne Parameter startet GUI, mit Parameter Console. Da mir hier schon immer geholfen wurde, hab ich natürlich auch hierzu erstmal hier gesucht ... und bin auch in gewisser Weise fündig geworden.

In den folgenden Threads gehts schon auch um dieses Thema:
Konsole oder was?
GUI Anwendung mit Consolen-Ausgabe
Ausgabe in DOS-Box

Da gehts einerseits um AllocConsole/GetStdHandle, andererseits um einen wirklich sehr charmanten Ansatz über Application.ShowMainform := false

Die hier gefundenen Ansätze hab ich daraufhin mal wie folgt probiert:

Delphi-Quellcode:

begin

// Ohne GUI starten, wenn Parameter KUNDE angegeben wurde
   if FloCmdLineParamFound( 'KUNDE' ) then begin

      RunKundenBatch();

   end else begin

      Application.Initialize;
      Application.Title := 'PGen';
      Application.CreateForm(TPGMain, PGMain);
  try
      Application.Run;
      except
         on E: Exception do
            Application.MessageBox( PChar( e.Message ),
                                    'Systemfehler',
                                    MB_OK+MB_ICONHAND+MB_DEFBUTTON1+MB_APPLMODAL);
      end;
   end;
end.

Variante 1:
(TConsole (wincon.pas) gibts im 2 Link. Schönen Dank auch an marabu)

Delphi-Quellcode:

// 
// ... andere Unit
// 

procedure RunKundenBatch();
begin
   with TConsole.Create do begin
      WriteStr('PGen v1.0'+CRLF);
      WriteStr('Kunde:'+CRLF);
      WriteStr(''+CRLF);
      WriteStr('Drücken Sie eine Taste zum Fortsetzen ...');
      ReadStr;
      Destroy;
   end;
end;

// Auszug aus WinCon.pas
constructor TConsole.Create;
begin
  inherited;
  AllocConsole;
  hIn  := GetStdHandle(STD_INPUT_HANDLE);
  hOut := GetStdHandle(STD_OUTPUT_HANDLE);
end;
procedure TConsole.WriteStr(s: string);
var
  iWritten: cardinal;
begin
  WriteFile(hOut, s[1], Length(s), iWritten, nil);
end;

Variante 2

Delphi-Quellcode:

procedure RunKundenBatch();
begin
// Auch eine sehr schöne Lösung, mit Bordmitteln
      Application.ShowMainform := false;
      AllocConsole;
      WriteLn('PGen v1.0');
      ReadLn;
      FreeConsole;
end;

Beide Varianten funktionieren soweit auch. Jedoch wird immer eine separate, neue Console geöffnet. Was ich gern erreichen würde, wäre, das Start und die dazugehörige Ausgaben in der aktuellen, bereits geöffneten Console - falls vorhanden - geschrieben werden.

In etwa so: DOS-Box ist offen, App wird dort mit Paramter gestartet und Ausgaben erscheinen in dieser DOS-Box und nicht in eincer neuen Console.

Aber wie komm ich an die Konsole, aus der heraus die App gestartet wurde?
Habt ihr dafür vielleicht ein paar Anregungen für mich?

Dank & Gruss
nru

[SirThornberry]

Das einfachste wird sein du erstellst 3 Anwendungen
1.) eine Starteranwendung welche je nach Parameter die 2te oder 3te Anwendung startet
2.) Gui app
3.) console app

[sirius]

@Sir: Die Startanwendung könnte auch gleichzeitig schon die Konsolenanwendung sein, oder?

Ich habe auch noch etwas probiert:
Variante 1:
Eine normale GUI-Anwendung und {$Apptype Console} einfügen.
Damit ist allerdings immer ein Console da.

Varinate2:

Delphi-Quellcode:

program Project1;


uses
  Forms,
  windows,
  Unit1 in 'Unit1.pas' {Form1};

{$R *.res}

// ist in D7 noch nicht enthalten:
function AttachConsole(dwProcessId:DWord):Bool;stdcall;
 external 'kernel32.dll';
const ATTACH_PARENT_PROCESS=DWORD(-1);


begin
  if paramcount=0 then
  begin
    Application.Initialize;
    Application.CreateForm(TForm1, Form1);
    Application.Run;
  end else
  begin
    if AttachConsole(ATTACH_PARENT_PROCESS) then
      writeln
    else
      allocConsole;
    try

      writeln('Here I am');
      readln;
    finally
      Freeconsole;
    end;
  end;
end.

Verhält sich aber auch eigenartig. (Edit: Was daran liegt, dass bei AttachConsole immer noch ein abschließend Readln im Code angehängt wird, oder was auch immer das ist)

[nru]

Das mit den 3 Apps war mir auch kurzzeitig mal in den Sinn gekommen ... habs aber verworfen, da ich dachte, es würde auch in einer gehen ;)


@sirius: Deine 2.Variante gefällt mir echt gut. Und klappt auch (eigentlich) ganz gut. Bis eben auf das von Dir geschilderte Verhalten. Vielleicht gibts dafür ja auch irgendwo/irgendwie eine Lösung.

Aber immerhin gibts jetzt einen Programmstart mit Ausgabe in der bereits geöffneten DOS-Box!


Thx,
nru

[himitsu]

Schau mal in meinen alten FileSplitter, dieser hab bei Programmstart eine Erkennung, ob der Programm über eine Console gestartet wurde und gibt dann auch Text dieser Console aus.

Die Console kannst du auch selber erzeugen, falls noch keine vorhanden ist und es aber über einen Parameter verlangt wird. (AllocConsole hast'e ja schon kennengelernt)

{$Apptype Console} besagt, daß das Programm eine Consolenanwendung ist und somit erstellt Windows beim Start eine Console, wenn sie noch nicht existiert.
Ergo: Belaß die Anwendung als GUI-Anwendung und reagiere auf eine existierende Console und/oder auf den gewünschten Parameter.

[add]
hier noch ein paar passende Beiträge/Themen:
Konsole oder keine Konsole? (Beitrag #9)
Konsolenfenster im GUI-Mode unterdrücken

[nru]

Hi,

auf den Thread "Konsolenfenster im GUI-Mode unterdrücken" und Eure dortige Diskussion über AttachConsole und das ReadLn() am Ende bin ich gerade eben auch gestoßen Das Verhalten hatte Sirius hier ja auch schon erwähnt.

Ich habs inzwischen so umgangen, indem ich am Ende der Konsolenvearbeitung WriteStr('Drücken Sie eine Taste zum Fortsetzen ...'); aufgenommen habe ... Anwender drückt Enter, Prompt kehrt zurück ;)

Somit läuft die Sache nun
- als reine GUI App (wenn über Explorer, Startmenü, Ausführen ohne Parameter gestartet wurde)
- mit neu erstellter Console und dortigen Ausgaben (wenn über Start->Ausführen mit Parameter)
- in bestehender Console (bei Start mit entsprechendem Parameter)

Deinen FileSplitter schau ich mir gleich an.

Vielen Dank für Euren perfekten Input! :thumb:

Gruss
nru


PS:

Zitat:

// ist in D7 noch nicht enthalten:

... und in meinem Favoriten, D5, natürlich auch nicht :wink:

[Ajin]

Hmm ist ATTACH_PARENT_PROCESS in D2009 nicht mehr aktiv?


[DCC Fehler] FSSystem.pas(30): E2003 Undeklarierter Bezeichner: 'ATTACH_PARENT_PROCESS'

[himitsu]

Es ist einfach nur nicht in den übersetzen Windows-Headern mit enthalten

Delphi-Quellcode:

const ATTACH_PARENT_PROCESS = LongWord(-1);

[Ajin]

Delphi-Quellcode:

program Project1;


uses
  Forms,
  windows;

{$R *.res}

function AttachConsole(dwProcessId:DWord):Bool;stdcall;
external 'kernel32.dll';
const ATTACH_PARENT_PROCESS=DWORD(-1);
var i:integer;


  begin
    if AttachConsole(ATTACH_PARENT_PROCESS) then
      writeln
    else
      allocConsole;
    try

      for I := 0 to 40000 do
      begin
      writeln(i);
      end;


      readln;
    finally
      Freeconsole;
    end;
end.

Das funktioniert unter Win7 x64 ohne Probleme, aber unter Windows 2000 gibts ne Fehlermeldung: Der Prozedur Einsprungpunkt "ATACHCONSOLE" wurde in der DLL kernel32.dll nicht gefunden.

[himitsu]

Das MSDN sagt zu AttachConsole:

Minimum supported client : Windows XP

Minimum supported server : Windows Server 2003

AllocConsole wäre ab Windows 2000 nutzbar, falls es dir helfen würde.

[Ajin]

:(
Ich glaub mein Problem lässt sich dann nicht lösen. Der Hintergrund meiner Konsolenversuche ist folgender:

Eine Java-Konsolenanwendung kann nicht direkt mit einer Prolog-Datei (.exe) kommunizieren, deshalb hat mich ein Kollege gefragt ob ich nicht Delphi als Schnittstelle zwischen JAVA und PROLOG einbinden kann. Es geht um eine hochkomplexe Wegewahl welche von Prolog errechnet wird.

Das JAVA Programm
- hat eine Konsolen-Scanfunktion
- hat eine Entscheidungsfunktion
- kann eine Konsolenanwendung starten
- kann KEINE Prolog-Eingaben tätigen !

Die Delphi Schnittstelle
- wird vom Java Tool gestartet und empfängt den Parameter (Wegpunkte) für Prolog
- startet Prolog und tätigt Eingaben (den Parameter mit dem Wegpunkt)
- liest das Ergebnis vom Prolog Programm und übergibt es wieder an das Java Tool. Dies entscheidet dann ob der Weg zum Ziel führt oder ob eine neue Wegeberechnung eingeleitet werden muss.

Das Prolog Programm
- Erwartet eine Eingabe (Parameter mit dem Wegpunkt)
- Errechnet ein Ergebnis und gibt es via Konsole als String aus

Wenn der errechnete Weg von Prolog nicht zielführend ist, entscheidet das Java Tool wo neu angesetzt werden muss und übergibt Delphi dann die neue Strecke.
Und das alles unter Windows 2000 :?

Um zu testen ob das JAVA Tool den Konsolenoutput von Delphi überhaupt scannen kann, wollte ich fix ein paar Konsolenzeilen mit Delphi erstellen.

Kann ich meinem Kollegen mit Delphi helfen oder ist das eher eine umgekehrte Pyramide?

[Memnarch]

Verzeiht die Nekromantie, aber es gibt hier eine Falschaussage, die ich für zukünftige Sucher/Finder dieses Threads klarstellen möchte:

Mit AttachConsole wird KEIN ReadLN ans Ende angefügt. Die aufrufende CMD wartet schlichtweg nicht auf euren Prozess und gibt dem user wieder direkt die Prompt. Bei eurem angeblichen "ReadLine" könnte ihr nämlich wie gewohnt fortfahren. DIe gestartete Applikatione bombt dann nur irgendwann dem user in die eingabe. Setzt einfach nen sleep vor euer writeln(10sekunden o.ä.). Solange euer prozess schläft könnt ihr in der cmd weiterarbeiten und nach ablauf der Zeit funkt euch euer programm in den Userinput.


Anscheinend wartet die CMD grundsätlich nicht auf GUI-Programme