Konsolenfenster im GUI-Mode unterdrücken

[naujo]

Hallo zusammen,

ich habe das folgende Problem:
Das Programm welches ich schreibe soll eine grafische Oberfläche verfügen und auch über die Kommandozeile sich bedienen lassen. Wenn die Kommandozeile verwendet wird dann kommt keine GUI. Wenn jetzt aber die GUI aufgerufen werden soll, dann erscheint im Hintergrund immer das Konsolenfenster.

Das möchte ich aber nicht anzeigen, weil den Anwender sonst zu sehr verwirrt.

Wenn ich aber die

Delphi-Quellcode:

{$APPTYPE CONSOLE}

Compiler-Direktive lösche, dann kann ich keinen Text mehr auf der Konsole ausgeben, es kommt dann immer eine Zugriffverletzung.

Hier mal ein Auszug aus dem Hauptprogramm:

Delphi-Quellcode:

begin
  Application.Initialize;
  Application.Title := 'Main';
  Application.CreateForm(TMainFrm, MainFrm);
  Application.CreateForm(TFrmInfo, FrmInfo);
  (...)

  if (not BatchMode) then
  begin
    (...)
    Application.Run;
  end
  else
  begin
    // Muss eingefuegt werden, da es sonst zu einem Programmabsturz kommt
    {$APPTYPE CONSOLE}
    (...)
    // Hier erfolgen dann Ausgaben in Konsolenfenster
  end;
end.

Vielen Dank dann schon mal für eure Antworten.

MfG

Naujo

[c113plpbr]

Hi Naujo,

nur dass es da keine missverständnisse gibt:

Delphi-Quellcode:

{$APPTYPE CONSOLE}

ist eine *compiler direktive*, d.h. es ist im grunde egal wo das dingens steht, selbst wenn die zeile in der es steht nicht "aufgerufen" wird, besitzt die anwendung dennoch ein konsolenfenster!
D.h. das mit ner einfachen if-abfrage zu lösen kannst du schonmal vergessen.

Wenn du nicht unbedingt eine ausgabe auf der konsole brauchst, sondern nur das programm ausführen willst, dann lass die $APPTYPE CONSOLE-Direktive weg, und erzeuge einfach nur keine graphische oberfläche. Das läuft dann auch in der konsole, nur eben ohne ausgabe & graphische oberfläche.

Eine weitere möglichkeit wäre evtl. noch, das konsolenfenster nach dem start des programmes zu verstecken. Also fenster suchen, und verstecken.

Andere möglichkeiten fallen mir dazu atm. nicht ein ...

ciao, Philipp

[jbg]

AllocConsole macht eine neue Konsole auf.

[r2c2]

Ich weiß jetzt nicht, ob du das hören willst, aber du könntest 2 Programme schreiben. Wenn du OO Programmierst sollte es kein Problem sein, aus der GUI ne Console zu machen.

Ich muss aber zugeben, dass ich wahrscheinlich auch einfach nur das Consolen-Fenster verstecken würde...

mfg

Christian

[naujo]

Moin moin,

Zitat:

Ich weiß jetzt nicht, ob du das hören willst, aber du könntest 2 Programme schreiben.

Das wollte ich auf jeden fall vermeiden. Aber es wäre kein Problem, weil ich alles in Klassen gekapselt habe. Und die Ausgaben sauber von einander getrennt habe, die Logik arbeitet unabhängig vom Modus (so es eigenlich immer sein soll, auch wenn man nur eine grafische Oberfläche oder nur aus Konsolenebene arbeitet).

Zitat:

Eine weitere möglichkeit wäre evtl. noch, das konsolenfenster nach dem start des programmes zu verstecken. Also fenster suchen, und verstecken.

Wie setzt man das in DeLphi um? Das stellt für mich die beste Lösung dar.

Vielen Dank für eure Antworten.

MfG

Naujo

[r2c2]

Zitat:

Zitat von naujo

Zitat:

Eine weitere möglichkeit wäre evtl. noch, das konsolenfenster nach dem start des programmes zu verstecken. Also fenster suchen, und verstecken.

Wie setzt man das in DeLphi um? Das stellt für mich die beste Lösung dar.

Such mal nach FindWindow(Ex). Damit bekommst du das Handle des Fensters. Zum Verstecken gibts auch ne Funktion(HideWindow? :gruebel: weiß nicht mehr). Auf jeden Fall fidest du was, wenn du danach suchst(DP, dsdt.info, swissdelphicenter.ch, goolge...).

mfg

Christian

[Olli]

1.) Diese Frage gibt es hier im Forum mindestens schon einmal
2.) Vergiß es!

Kurze Begründung: a.) habe ich das sehr lange probiert und dazu auch versucht mit RE den Konsolen auf die Spur zu kommen. b.) kann es nicht gehen, weil der PE-Loader bereits die Konsole für den Prozeß alloziert (bei APPTYPE CONSOLE). Damit bist du machtlos und die Konsole wir in jedem Fall kurz erscheinen. Selbst Tricks mit der PEB/TEB (nur unter NT) waren zwecklos. Man dreht sich dort im Kreis, weil die Überprüfung erst geschehen kann, wenn das Programm bereits läuft - zu dem Zeitpunkt existiert aber bereits eine Konsole oder sie existiert eben nicht (APPTYPE GUI) - dann gibt's allerdings auch keine Elternkonsolhandles.

Ich denke mal, daß du das gleiche erreichen möchtest wie ich bei meinem RShutdown2 damals: daß dein Programm von einer "Elternkonsole" aus gestartet werden kann und dann dort seine Ausgaben/Eingaben bekommt. Ich will nicht behaupten, daß es komplett unmöglich sei, aber es ist doch recht fragwürdig - zumal bei dem Aufwand in Sachen RE usw.

Ich habe es übrigens dann ganz pragmatisch über FreeConsole() gelöst. So wird zwar die Konsole kurz angezeigt, ich habe aber dennoch volle Konsolenfunktionialität, wenn die Parameter dies erfordern. Logischerweise kannst du FindWindow() usw. dann auch knicken, weil Konsolennamen theoretisch verschieden sein können. FreeConsole() tut aber seinen Job hervorragend, da es eh nur eine Konsole (pro Prozeß) geben kann ;) ... sonst würde ja AllocConsole() das Handle zu einer beliebigen neu erzeugten Konsole zurückliefern und nicht nur Erfolg oder Mißerfolg ;)

Ab Windows XP gibt's noch AttachConsole(), welches dem o.g. Ziel (wenn dies denn deines ist) durchaus helfen könnte. Ich werde mir das mal im Disassembler angucken und vielleicht mit einer Lösung auch ab NT4 rüberrücken. Aber Win9x-Kompat. kannste da definitiv knicken.

Nachtrag: Ich habe es mir gerade angeguckt. Es hängt doch einiges mehr dran. Das größte Problem aber sind die Client/Server-Nachrichten (CSR-Messages), welche nunmal leider nicht dokumentiert sind. Wenn du eine CSR auf Windows 2000 mit einer bestimmten ID zum Laufen bekommen hast, kannst du dir auf Windows XP damit gut und gerne Hardware zerschiessen. Ist also nix wirklich kompatibles. Zumal fraglich ist, ob diese spezifische CSR schon in Windows 2000 existieren würde. Ich werde es mal demnächst versuchen, könnte ja sein, daß es auch ohne die geht. Aber wer weiß :-/

[naujo]

Moin,

also wenn das alles so einen erheblichen Aufwand darstellt, dann muss halt der Anwender mit einem Konsolenfenster im Hintergrund leben, dafür kann ich dann auch nix.

Und was ich nicht erwähnt hatte das Programm soll auch ab Win 95 bzw. Win NT 4 laufen. Ich hatte gedacht, dass es irgendeine Möglichkeit gibt, dass per Schalter oder API-Aufruf einfach zu unterdrücken.

Vielen Dank aber schon mal für eure Mühe.

MfG

Naujo

[Olli]

Zitat:

Zitat von naujo

Und was ich nicht erwähnt hatte das Programm soll auch ab Win 95 bzw. Win NT 4 laufen. Ich hatte gedacht, dass es irgendeine Möglichkeit gibt, dass per Schalter oder API-Aufruf einfach zu unterdrücken.

Leider nein, da dieses Flag wie gesagt nicht von der EXE sondern schon davor ausgewertet wird ;) ...

[himitsu]

hab jetzt mal einiges von da oben ausprobiert...

AllocConsole und AttachConsole erzeugen beide eine neue Console (unter WinXP)
sieht vorallem witzig aus wenn das Programm von einer Console (oder Batchfile) aus gestartet wurde und nun zwei davon da sind.

mit $APPTYPE CONSOLE hatte ich es schon versucht, aber da bleib ich nun bei GUI (das Programm läuft ja vorwiegend damit)
OK, das Programm arbeitet zwar NonVCL und da werden die Fenster genauso mit Console, als auch ohne (GUI) angezeigt, aber da stört mich schon dieses Konsolenfenster, wenn es nicht benötigt wird.


ich wollte einfach nur eine Statusmeldung in der Konsole ausgebn (wenn diese exisiert) ...
gibt es da nun inzwischen irgendwo eine Lösung dafür?
Input wird nicht benötigt, ich würde nur genr irgendwie ein/zwei Zeilen dareinschreiben.

MfG <(^_^<)


[add]
aaaalso, FreeConsole schließt zwar nur die vom Programm erzeugte
Konsoleund Eine z.B. von 'ner Batch-Datei bleibt geöffnet,
aber nach dem Aufruf st dennoch (war ja irgendwie klar) die Verbindung
zur "Batch-Datei"-Konsole futsch.

Delphi-Quellcode:

{$APPTYPE CONSOLE}
Sleep(2000);
WriteLn('123');              // << in "alter" Konsole
Sleep(2000);
if FreeConsole then A := 'f';
Sleep(2000);
{$i-} WriteLn('456'); {$i+}  // << dieses wird natürlich nie ausgegeben
Sleep(2000);
if AllocConsole then A := A + 'a';
Sleep(2000);
{$i-} WriteLn('789'); {$i+}  // << Ausgabe in neuer Konsole (AllocConsole)
Sleep(2000);                 // auch geschützt, da beim der mit AllocConsole
Exception(998, [A]);         // erzeugten Konsole zwar der Text geschrieben wird,
                             // aber dennoch eine Exception auftritt

[add2]
wenn jetzt dieses "kurzzeitige" Konsolenfenster und die Beschränkung auf WinXP/Vista nich wäre,
dann könnte man es wohl so lassen :stupid:

Delphi-Quellcode:

{$APPTYPE CONSOLE}
FreeConsole;
isConsole := AttachConsole(ATTACH_PARENT_PROCESS);

if isConsole then WriteLn('irgendwas');

dieses hat mir auch gleich mal eine Lösug gegeben, wie ich automatisch rausbekommen kann ob GUI oder Konsole.