Starten wahlweise mit und ohne GUI

[jus]

Ich hätte eine konzeptionielle Frage und zwar habe ich ein Programm das einerseits in einer Batchdatei mit Parameter aufgerufen wird, wo kein Fenster aufpoppen soll, und falls kein Parameter mitgegeben wird, soll es mit GUI gestartet werden. Derzeit löse ich so:

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
begin
  case paramcount of
    1: begin
         showmessage('Zuwenige Parameter. Programm wird fortgesetzt.');
       end;
    else  
    begin
      Mach_Was_ohne_GUI(paramstr(2)); //Parameter wurde angegeben
      Halt; 
    end;
  end;
end;

Falls ein Parameter angegeben wurde, wird es ausgeführt und danach das Programm in FormCreate brutal mit "Halt" beendet. Funktionert eigentlich auch zufriedenstellend. Doch vermutlich gibt es elegantere Lösungen. :oops: Wie könnte man es besser machen?

lg,
jus

[KodeZwerg]

Hallo jus, ja es gibt einen eleganteren Weg der auch Deine Applikation schneller macht! (Jedenfalls wenn ein Parameter übergeben wurde) :-)
Mach das in .dpr ohne vorher GUI zu laden.

edit
also so wie hier in diesem Beispiel:

Delphi-Quellcode:

program DFK;

uses
  Forms,
  uMain in 'uMain.pas' {frmKnips},
  uClear in 'uClear.pas' {frmClear};

{$R *.res}

begin
  if ParamCount = 0 then // wenn keine Parameter angegeben wurden, dann lade die GUI
  begin
    Application.Initialize;
    Application.MainFormOnTaskbar := True;
    Application.Title := 'Der Fenster Knipser by KodeZwerg';
    Application.CreateForm(TfrmKnips, frmKnips);
    Application.CreateForm(TfrmClear, frmClear);
    Application.Run
  end
  else
  begin
// Code ohne GUI fängt hier an....
// Du musst in Uses das einbinden wo Du ohne GUI Zugriff drauf benötigst, eventuell Windows.pas für API?
  end;
end.

War es das was Du meintest?

[jaenicke]

Wir speichern Application dort in eine eigene Variable, damit die IDE an der Stelle nicht immer versucht automatisch etwas zu ändern, z.B. wenn man ein neues Formular hinzufügt.
Sprich:

Delphi-Quellcode:

var
  App: TApplication;
begin
  App := Application;
  if ...
  begin
    App.Initialize;
...

[jus]

@KodeZwerg
Ja stimmt, einfach in die dpr schreiben. Die Lösung lag eigentlich auf der Hand, aber im nachhinein ist man immer schlauer. :oops: Vielen Dank!

@jaenicke
Vielen Dank für den coolen Trick!

lg,
jus

[Uwe Raabe]

Zumindest bisher ist es offenbar so, daß die IDE sämtlichen Code vor dem

Delphi-Quellcode:

Application.Initialize

in Ruhe lässt. Deswegen wäre auch dieser Ansatz eine mögliche Lösung, bei der die automatischen Eingriffe der IDE weiterhin möglich bleiben:

Delphi-Quellcode:

begin
  if ParamCount > 0 then begin
    { Kommandozeile abarbeiten }
    Halt(0);
  end;

  Application.Initialize;
  Application.MainFormOnTaskbar := True;
  ...
end.

Es ist allerdings zu beachten, daß mit diesen Tricks immer noch kein Konsolenprogramm daraus wird. Insbesondere werden irgendwelche Aufrufe von Write/-ln und Read/-ln auf die impliziten IO-Kanäle Input und Output nicht funktionieren.

[himitsu]

Warum ermorden (

Delphi-Quellcode:

Halt(0);

) eigentlich immer welche ihre Anwendung, anstatt das zu machen, was sie eigentlich wollten?
Also die Anwendung Ausführung abzubrechen (

Delphi-Quellcode:

Exit;

).

[Schokohase]

Den Code zum Auswerten/Abarbeiten der Parameter würde ich auslagern in eine andere Unit

Delphi-Quellcode:

unit CmdLineProcessor;

interface

function ProcessCmdLine() : Boolean;

implementation

function ProcessCmdLine() : Boolean;
begin
  // Hier eigentlich etwas sinnvolles mit den Parametern anfangen
  Result := ParamCount > 0;
end;

In der DPR genügt dann eine Zeile Code:

Delphi-Quellcode:

begin
  if ProcessCmdLine() then Exit;

  Application.Initialize;
  Application.MainFormOnTaskbar := True;
  ...
end.

[KodeZwerg]

Zitat:

Zitat von jus (Beitrag 1404010)

Ja stimmt, einfach in die dpr schreiben. Die Lösung lag eigentlich auf der Hand, aber im nachhinein ist man immer schlauer.

Gern geschehen, auch wenn andere meinen Ansatz als falsch empfinden mögen, ein "Halt()" finde ich kann nie ein gutes Ende für ein Programm sein. Viel Erfolg mit welcher Methode auch immer!:thumb:

[Luckie]

Spielt keine Rolle ob Halt oder Exit verwendrt wird. Tot ist tot. Mund Windows räumt automatisch nach Ende des Proceses auf.

[KodeZwerg]

Ich gehe da mehr nach Anleitung,

Zitat:

Beschreibung
Bricht ein Programm ab.

Halt löst einen Programmabbruch aus und gibt die Steuerung an das Betriebssystem zurück.

Um ein Delphi-Programm normal zu beenden, rufen Sie die Methode Terminate in dem globalen Application-Objekt auf. Wenn in der Anwendung keine Unit verwendet wird, die ein Application-Objekt bereitstellt, rufen Sie die Prozedur Exit aus dem Hauptprogrammblock auf.

Exitcode ist ein optionaler Ausdruck, der einen Beendigungscode für das Programm festlegt.

und da steht es mit Exit bzw Terminate für TApplication.
Bei Halt() werden da nicht alle Close-Events übersprungen und es geht direkt zum Ende ohne Möglichkeit sein Programm aufzuräumen?

[Uwe Raabe]

Zitat:

Zitat von Luckie (Beitrag 1404031)

Spielt keine Rolle ob Halt oder Exit verwendrt wird.

Der Unterschied zwischen Halt und Exit ist, daß bei Exit eventuell noch vorhandene finally-Blöcke in der DPR aufgerufen werden. Die finalization-Blöcke der Units werden in beiden Fällen abgearbeitet.

[Luckie]

OK, das ist jetzt aus Sicht des schon zum Tode Verurteilten. Ich wollte aber damit sagen, dass es Windows egal ist, wie ein Prozess beendet wird.

[Hobbycoder]

Zitat:

Zitat von Uwe Raabe (Beitrag 1404014)

Es ist allerdings zu beachten, daß mit diesen Tricks immer noch kein Konsolenprogramm daraus wird. Insbesondere werden irgendwelche Aufrufe von Write/-ln und Read/-ln auf die impliziten IO-Kanäle Input und Output nicht funktionieren.

Wie würden denn das realisierbar sein?

[KodeZwerg]

In dem man eine Konsole erstellt vermutlich, in der man dann arbeiten kann.

[Uwe Raabe]

Zitat:

Zitat von Hobbycoder (Beitrag 1404060)

Wie würden denn das realisierbar sein?

Eigentlich gar nicht: https://blogs.msdn.microsoft.com/old...01-00/?p=19643

[KodeZwerg]

Ich habe mir den Artikel und auch den Sub-Artikel durch gelesen, so wie ich es anstelle wird dort nicht aufgeführt als possibility. In mehreren meiner mini-Apps kann man die App über Console oder GUI steuern, erstellt wird die App als Consolen-Anwendung, bei Start überprüfe ich Parameter, entweder schließe ich Console und übergebe die Kontrolle an die GUI oder ich verweile in der Console und habe da meinen Spass. Auch wenn es falsch sein mag, es funktioniert bis jetzt ohne negative Auswirkungen zu vernehmen. (die GUI wird bei Laufzeit nonVcl erstellt aber das Prinzip müsste überall funktionieren, ich habe es aber nur auf diese Weise bis jetzt verwendet.)

[Fritzew]

https://stackoverflow.com/questions/...e-command-line
Sollte etwas dabei sein.....

[Uwe Raabe]

Ich bin da lieber auf der sicheren Seite, was unerwartete Anwender-Szenarien und zukünftige Windows-Updates betrifft, und liefere in so einem Fall immer zwei Executables aus. Die Console-Version bekommt dann in der Regel noch ein Cmd am Ende des Namens spendiert, damit auch jeder weiß, womit er es zu tun hat.

[KodeZwerg]

Ist man mit Delphi in der Lage sich ein mini .COM file zu kreiiren als Loader wenn man zwei getrennte Anwendungen erstellt?
Also das in dem App.com die Parameter geprüft werden und je nach Parameter dann die AppCon.exe bzw App.exe geladen wird und entsprechende Parameter rangehängt werden beim Aufruf.

[Fritzew]

Zitat:

Zitat von KodeZwerg (Beitrag 1404080)

Ist man mit Delphi in der Lage sich ein mini .COM file zu kreiiren als Loader wenn man zwei getrennte Anwendungen erstellt?
Also das in dem App.com die Parameter geprüft werden und je nach Parameter dann die AppCon.exe bzw App.exe geladen wird und entsprechende Parameter rangehängt werden beim Aufruf.

Aus welchem Jahrhundert stammst Du den? Com war MsDos.....

mach die ne kleine *.exe wenn schon......

[Uwe Raabe]

Zitat:

Zitat von KodeZwerg (Beitrag 1404080)

Ist man mit Delphi in der Lage sich ein mini .COM file zu kreiiren als Loader wenn man zwei getrennte Anwendungen erstellt?
Also das in dem App.com die Parameter geprüft werden und je nach Parameter dann die AppCon.exe bzw App.exe geladen wird und entsprechende Parameter rangehängt werden beim Aufruf.

Du meinst, wie bei devenv.com und devenv.exe? Nein, da ist mir bei Delphi keine Möglichkeit bekannt.

Aber dann kannst du ja auch gleich eine AppCmd.exe bauen, die ohne Parameter dann die App.exe aufruft. Wie in einigen anderen Lösungsansätzen flackert dann halt kurz eine Konsole auf.

Ich verstehe auch irgendwie den Sinn nicht: Wenn ich eine CmdLine-Anwendunge ohne Parameter aufrufe und die dann nicht arbeiten kann, dann soll sie mir günstigstenfalls bitte ihre Aufrufkonventionen mitteilen, aber in jedem Fall einen ErrorCode zurückgeben, den ich abfragen kann. Auf keinen Fall sollte sie eine GUI aufmachen, was z.B. in einem unsichtbarem Desktop, einem Build-Skript oder einem FinalBuilder-Projekt gar nicht gehen oder sogar böse enden würde.

[Fritzew]

Zitat:

Zitat von Uwe Raabe (Beitrag 1404083)

Zitat:

Zitat von KodeZwerg (Beitrag 1404080)

Ist man mit Delphi in der Lage sich ein mini .COM file zu kreiiren als Loader wenn man zwei getrennte Anwendungen erstellt?
Also das in dem App.com die Parameter geprüft werden und je nach Parameter dann die AppCon.exe bzw App.exe geladen wird und entsprechende Parameter rangehängt werden beim Aufruf.

Du meinst, wie bei devenv.com und devenv.exe? Nein, da ist mir bei Delphi keine Möglichkeit bekannt.

Aber dann kannst du ja auch gleich eine AppCmd.exe bauen, die ohne Parameter dann die App.exe aufruft. Wie in einigen anderen Lösungsansätzen flackert dann halt kurz eine Konsole auf.

Ich verstehe auch irgendwie den Sinn nicht: Wenn ich eine CmdLine-Anwendunge ohne Parameter aufrufe und die dann nicht arbeiten kann, dann soll sie mir günstigstenfalls bitte ihre Aufrufkonventionen mitteilen, aber in jedem Fall einen ErrorCode zurückgeben, den ich abfragen kann. Auf keinen Fall sollte sie eine GUI aufmachen, was z.B. in einem unsichtbarem Desktop, einem Build-Skript oder einem FinalBuilder-Projekt gar nicht gehen oder sogar böse enden würde.

Dem ist nichts!!! hinzuzufügen :-)

[Schokohase]

Die Variante auf SO ist ja ganz nett, allerdings reicht es völlig aus, sich an die Parent-Console dranzuhängen, und wenn das fehlschlägt eine eigene Console zu eröffnen:

Delphi-Quellcode:

uses
  Winapi.Windows;

const
  ATTACH_PARENT_PROCESS = DWORD( -1 );

function AttachConsole( dwProcessID: DWORD ): Boolean; stdcall; external 'kernel32.dll';


if not AttachConsole( ATTACH_PARENT_PROCESS ) and not AllocConsole( )
  then
    RaiseLastOSError( );
try
  Write('Here I am!');
  ReadLn;
finally
  FreeConsole();
end;

ABER das ist immer noch nicht dasselbe, als wenn man eine echte Konsolen-Anwendung hat, denn die verhält sich noch ein wenig anders.

[KodeZwerg]

Mein Grund-Gedanke bei meiner Frage wegen .COM file war halt das sich User falls ich App nun splitte, nicht an neue Aufruf-Konventionen gewöhnen müssen sondern alles bleibt erstmal so wie es ist, man tippt "App" in die Console und "App" startet.
Da man anscheinend kein .com erstellen kann ist mir klar wie ich es mit einem .exe regeln kann, Danke.
Ich bin aus der Vergangenheit/Gegenwart und Zukunft @Fritzew :lol:

[EWeiss]

Zitat:

Zitat von KodeZwerg (Beitrag 1404086)

Ich bin aus der Vergangenheit/Gegenwart und Zukunft @Fritzew :lol:

Was soll uns das jetzt sagen. Hmm... verstehe ich jetzt nicht.

gruss

[Rollo62]

Zitat:

Zitat von KodeZwerg:
Ich bin aus der Vergangenheit/Gegenwart und Zukunft @Fritzew
Was soll uns das jetzt sagen. Hmm... verstehe ich jetzt nicht.

Na ist doch klar: Der KodeZwerg ist halt ein E8 Gosset Polytope, also ein Quasikristall aus der 8. Dimension, für den sind alle Zeit und Raum immer und überall gleichzeitig da.
Das wird sicher nochmal spannend werden, da freue ich mich auf seine Geschichten :stupid:

[OT]
Entschuldigung: :oops: (zu spät)
[/OT]

[KodeZwerg]

Zitat:

Zitat von Fritzew (Beitrag 1404082)

Aus welchem Jahrhundert stammst Du den?

darauf

Zitat:

Zitat von KodeZwerg (Beitrag 1404086)

Ich bin aus der Vergangenheit/Gegenwart und Zukunft @Fritzew

darauf

Zitat:

Zitat von Rollo62 (Beitrag 1404091)

Der KodeZwerg ist halt ein

dazu
Und wenn, dann bin ich HAL9000 :warn: