Lazarus und Debugging und "Win32 GUI APplication" -WG

[Nimral]

Guten Abend,

heute bin ich wieder unterwegs, um eine Seltsamkeit zu klären: manchmal möchte ich ein paar billige billige Bildschirmausgaben haben, um einen Programmlauf zu verfolgen. Die einfachste Möglichkeit scheint laut Doku zu sein, LazLogger einzubinden und DebugLn zu nützen. Das hat aber unter Windows erst einmal nichts gebracht.

- Ich meine mich zu erinnern, dass ich irgendwann mal irgendwo ein grafisches "Nachrichten" Fenster gefunden hatte? Kann es aber nicht mehr finden. Kann aber auch sein, dass ich Lazarus mit irgendeiner anderen IDE verwechsle. (Anm: ja, ich meine, es gab sowas in Delphi RAD Studio).

Im Moment helfe ich mir damit, unter den Projekt-Optionen die Option "Win32 GUI Application" abzuwählen. Dann bekomme ich eine Textkonsole. Nur ... da kann ich sowieso hinschreiben, einfach mit writeln und ganz ohne DebugLn oder Lazlogger.

Wieso soll ich bei einer Windows 32 GUI Applikation diese Option abwählen? Wozu ist sie überhaupt gut?

HG, Armin.

[wp_xyz]

Wenn du mit aktivierter Checkbox "Win32 GUI application" ein WriteLn im Code ausführen willst, erhältst du einen Absturz "File not open" (weil die Standardausgabe nicht exisistiert). Du musst also, wenn du "WriteLn-Debugging" betreiben willst, die Checkbox abwählen und bekommst das Konsolenfenster, in dem die Ausgaben erscheinen. Wenn die Konsole nicht permanent erscheinen soll (was bei Windows ja unüblich ist), musst du nach dem Debuggen also die WriteLn-Anweisungen wieder entfernen und die Checkbox wieder setzen. Wenn du irgendwo ein WriteLn vergisst, "freuen" sich deine User...

Arbeitest du dagegen mit DebugLn, kann die Anweisung im Code verbleiben, der Code arbeitet sowohl bei aktivierter oder deaktivierter Checkbox. Außerdem hat DebugLn auch den Vorteil, dass die Ausgaben in eine Log-Datei umgeleitet werden, wenn keine Konsole vorhanden ist (also "Win32 GUI application" markiert ist).

[Nimral]

Ookey. Das macht Sinn - irgendwie

Hat denn dieser -WP Schalter nur den einzigen Sinn, dass mein Programm zusätzlich eine Konsole "mitschleppt" (bzw. eigentlich dass eben KEINE Konsole erzeugt wird)? Hat er noch andere Verhaltensänderungen zur Folge?

Eigentlich stünde das - habe ich jetzt entdeckt - durchaus im Wiki, aber m.E. ziemlich verquer.

No output is written if stdout is closed - for example when the application is {$AppType Gui}, or compiled with -WG on Windows (see Compiler options / Linking / Target OS specific options).

Also ... wenn ich eine Konsole brauche, muss ich -WG wegnehmen, was dann die Wirklung von "Win32 GUI Application" in den Projektoptionen ist? Ich habe auf Anhieb mal nicht gerafft, wie das Ganze zu verstehen ist ... meine Applikation ist natürlich genauso GUI wie vorher. Und {$AppType Gui} (das ich in keinem meiner Lazarus Programme je gesehen habe obwohl sie bis auf wenige Ausnahmen alle GUI Applikationen sind) spielt da auch noch irgendwie mit rein? Ich habe mal testweise eine Console Application erzeugt, da findet sich auch kein {$Apptype Console}. Scheint dass diese Option in Lazarus überhaupt nicht verwendet wird?

Danke wieder mal, Armin.

[corpsman]

Also meine ConfigTD Anwendung hat immer das -wg Flag gesetzt und prüft im Startup ob die aktuelle Instanz gerade eine Console braucht oder nicht

Code: Alles auswählen

{$IFDEF Windows}
    If lowercase(ParamStrUTF8(i)) = '-c' Then Begin
      AllocConsole; // in Windows unit
      IsConsole := True; // in System unit
      SysInitStdIO; // in System unit
      SetConsoleOutputCP(CP_UTF8);
    End;
{$ENDIF}

Damit wird die Konsole dann "Nachträglich" initialisiert, du musst dann nur noch dafür sorgen, das erst danach mittels Writeln auf die Konsole zugegriffen wird

[Nimral]

@Corpsman

das fand ich spannend! Ich dachte, ich verdrahte das mal mit dem Debug-Schalter, weil das meinem häufigsten Anwendungsfall entsprechen würde.

Code: Alles auswählen

program project1;

{$mode objfpc}{$H+}

uses
 {$IFDEF UNIX}
  cthreads,
   {$ENDIF} {$IFDEF HASAMIGA}
  athreads,
   {$ENDIF}
  Interfaces, // this includes the LCL widgetset
  Forms,
  Windows,
  Unit1 { you can add units after this };

{$R *.res}

begin
  {$IFOPT D+}
      AllocConsole; // in Windows unit
      IsConsole := True; // in System unit
      SysInitStdIO; // in System unit
      SetConsoleOutputCP(CP_UTF8);
      writeln('Debug output');      
  {$ENDIF}
  RequireDerivedFormResource := True;
  Application.Scaled := True;
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

Leider klappt es in meinem kleinen Testprogrämmchen nicht wie erhofft.

Das Ergebnis: es geht eine Konsole auf, writeln stürzt nicht mehr ab, aber es erscheint auch nichts in der Konsole. Damit die Ausgabe klappt, muss ich nach wie vor in den Projekt-Optionen "Windows GUI Application" ausknipsen. Dann kann ich das Ganze ebenso gut gleich weglassen.

Armin.

[PascalDragon]

Hat denn dieser -WP Schalter nur den einzigen Sinn, dass mein Programm zusätzlich eine Konsole "mitschleppt" (bzw. eigentlich dass eben KEINE Konsole erzeugt wird)? Hat er noch andere Verhaltensänderungen zur Folge?

Der einzige andere große Unterschied ist, wenn du deine Anwendung innerhalb einer Konsole startest: ist es eine GUI Anwendung, so kannst du danach die Konsole direkt weiter verwenden, ist es eine Konsolenanwendung, so kannst du nur mit dieser interagieren, bis der Prozess sich beendet.

No output is written if stdout is closed - for example when the application is {$AppType Gui}, or compiled with -WG on Windows (see Compiler options / Linking / Target OS specific options).

Also ... wenn ich eine Konsole brauche, muss ich -WG wegnehmen, was dann die Wirklung von "Win32 GUI Application" in den Projektoptionen ist? Ich habe auf Anhieb mal nicht gerafft, wie das Ganze zu verstehen ist ... meine Applikation ist natürlich genauso GUI wie vorher. Und {$AppType Gui} (das ich in keinem meiner Lazarus Programme je gesehen habe obwohl sie bis auf wenige Ausnahmen alle GUI Applikationen sind) spielt da auch noch irgendwie mit rein? Ich habe mal testweise eine Console Application erzeugt, da findet sich auch kein {$Apptype Console}. Scheint dass diese Option in Lazarus überhaupt nicht verwendet wird?

Die Option hat erstmal nichts mit deiner Anwendung selbst zu tun. Es ist eine Eigenschaft eines Windowsprozesses, ob dieser standardmäßig eine Konsole bekommt oder nicht und das wird eben über die Option -WG oder die Direktive $AppType gesteuert (das ist dann letztlich in den Metadaten der Binärdatei gespeichert und Windows wertet die beim Starten aus). Die Direktive gewinnt da übrigens, wenn sie vorhanden ist, weswegen Lazarus in seinen Projektvorlagen diese Direktive eben nicht verwendet (damit es über die Projekteinstellungen steuerbar bleibt).

Die RTL reagiert dann darauf, ob die Anwendung als GUI- oder Konsolenanwendung kompiliert wurde und richtet die Standardein- und -ausgabe entsprechend ein.

[corpsman]

@Nimral,

hast recht bei mir geht es wenn ich es vom Scratch mache auch nicht, muss mal noch rausfinden wo da genau der unterschied. Als Alternative geht aber auch das hier (Quelle: https://forum.lazarus.freepascal.org/in ... ic=41795.0 ):

Project1.lpr

Code: Alles auswählen

program project1;

{$mode objfpc}{$H+}

uses
  {$IFDEF UNIX}
  cthreads,
  {$ENDIF}
  {$IFDEF HASAMIGA}
  athreads,
  {$ENDIF}
  Interfaces, // this includes the LCL widgetset
  Forms, Unit1   , windows
  { you can add units after this };

{$R *.res}

begin
  ShowWindow(GetConsoleWindow, SW_HIDE);
  RequireDerivedFormResource:=True;
  Application.Scaled:=True;
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

Unit1.pas

Code: Alles auswählen

Procedure TForm1.Button1Click(Sender: TObject);
Begin
  // Button zum Anzeigen der Console
  button1.enabled := false;
  ShowWindow(GetConsoleWindow, SW_Show);
End;

Procedure TForm1.Button2Click(Sender: TObject);
Begin
  writeln('Test');
End; 

[Nimral]

Langsam lichten sich die Nebel Ich denke, dank diesem Hinweis habe ich einen Weg gefunden der mir passt, vielen Dank!

Ich bin es gewohnt, Debug-spezifischen Code in

Code: Alles auswählen

{$IFOPT D+}
 ...
{$ENDIF}

einzuschließen.

Bisher habe ich dann den Weg über die Build-Configs Release + Debug genommen:

- Unter "Config and Target" die Option "Win32 gui application (-WG)" ausgeknipst
- Unter "Additions and Overrides" in der Build-Mode Config "Release" als Option "-WG" eingetragen

Pfui Deibel, das ist schon ein Haufen fehlerträchtiger, unübersichtlicher Klatsch für so eine triviale Aufgabe. Dafür ist es "maximal buntifiziert".

Folgender Dreizeiler in der .lpr Datei passt m.E. besser zu meinem Geschmack, tut das selbe, ist klarer (weil in der Source kommentierbar), und hat den Vorteil dass die Default-Optionen des Projekts bleiben können wie gewohnt:

Code: Alles auswählen

{$IFOPT D+}
        {$AppType CONSOLE}
{$ENDIF}

Zusätzlich kann man sich aussuchen, ob man mit Writeln schreibt (Writeln ohne Absicherung mit {$IFOPT D+} lassen das Programm in der Release-Config abstürzen), oder mit LazLogger + DebugLn (DebugLn ohne Absicherung mit {$IFOPT D+} kosten sinnlos Laufzeit durch einen mehr oder weniger leeren Prozeduraufruf).

- Habe ich das jetzt soweit richtig zusammengefasst dass ich es wagen kann, das LazLogger Wiki zu ergänzen, damit EInsteiger schneller zum Ziel kommen?
- Gibt es noch andere Dokus für Lazarus zum Thema Debugging (allgemein), wo ein Hinweis angebracht wäre
- Inwiefern trifft das auch für andere Plattformen zu? Macht z.B. Linux per Default ein Konsolenfenster für Lazarus-Projekte, gibt es ein Standardfenster für StdOut das jeder kennt, oder muss man es auch dort erst irgendwie aktivieren und an Lazarus anhängen?

Armin.

[PascalDragon]

Folgender Dreizeiler in der .lpr Datei passt m.E. besser zu meinem Geschmack, tut das selbe, ist klarer (weil in der Source kommentierbar), und hat den Vorteil dass die Default-Optionen des Projekts bleiben können wie gewohnt:

Code: Alles auswählen

{$IFOPT D+}
        {$AppType CONSOLE}
{$ENDIF}

Zusätzlich kann man sich aussuchen, ob man mit Writeln schreibt (Writeln ohne Absicherung mit {$IFOPT D+} lassen das Programm in der Release-Config abstürzen), oder mit LazLogger + DebugLn (DebugLn ohne Absicherung mit {$IFOPT D+} kosten sinnlos Laufzeit durch einen mehr oder weniger leeren Prozeduraufruf).

Bitte beachte, dass der D-Schalter für DebugInfo steht und über die -gXXX-Optionen gesteuert wird und je nach Einstellungen vom Compiler auch selbstständig überschrieben/geändert wird, weil er zum Beispiel keine Debug Informationen für ein System generieren kann. Außerdem kann Unit A mit Debuginformationen kompiliert sein und Unit B ohne.

Besser nutze ein explizites Define und prüfe dieses mittels IFDEF oder (für komplexere Ausdrücke) IF DEFINED(...).... (Wobei auch hier Units in unterschiedlichen Zuständen kompiliert sein können)

- Inwiefern trifft das auch für andere Plattformen zu? Macht z.B. Linux per Default ein Konsolenfenster für Lazarus-Projekte, gibt es ein Standardfenster für StdOut das jeder kennt, oder muss man es auch dort erst irgendwie aktivieren und an Lazarus anhängen?

Unter *nix-Systemen wird der AppType ignoriert, da diese keine Unterscheidung von GUI- und nicht-GUI-Anwendungen kennen. Dort ist Writeln immer verfügbar, auch wenn es an keinem Terminal hängt, außer es Output wurde explizit mit FileClose bzw. Close geschlossen (ähnliches für Input und StdErr).

Lazarus bietet zum Beispiel auf Linux ein Terminalfenster an (ich glaube es ist unter Ansicht -> Debuggerfenster, bin mir gerade aber nicht ganz sicher). Alternativ kannst du in den Startparametern ein Startprogramm einstellen, dieses wird dann genutzt, um deine Anwendung zu starten (das war vor allem in der Zeit vor dem Terminalfenster wichtig, ist aber auch noch heute je nach Plattform und was du ausgibst (z.B. spezielle Steuerzeichen für das Terminal) sinnvoll). Es ergibt sich bei der Benutzung aber eventuell Probleme mit dem Debugger.

[Nimral]

Ich kann Dir nicht bis ganz zum Ende folgen

weil er zum Beispiel keine Debug Informationen für ein System generieren kann

das interpretiere ich mal so, dass das nur zutrifft, wenn der FPC Compiler das Erstellen von Debug-Infos für eine bestimmte *Plattform* überhaupt nicht unterstützt? Anders gesagt, es kann nicht sein, dass der Compiler für ein bestimmtes Projekt WIndows oder Linux Debug-Infos erzeugen kann, und für ein Anderes ncht? Das trifft eher zu für die vielen exotischen Plattformen auf denen FPC auch verfügbar ist, die aber eventuell keinen Debugger untersttzen?

Das mit der Variable hatte ich auch eine Weile so gemacht, ich habe sie idR DEBUG genannt,

Problemchen: ich habe jedes Mal wieder vergessen, wo ich die Variable setzen muss. Ich habs schon wieder vergessen Ich glaub, es war -d[Name] bei den Compiler-Optionen? Jemand der nach mir kommt und sich Lazarus installiert und die Sourcen aus der Versionsverwaltung lädt muss da erst mal draufkommen.

Hin und wieder habe ich es auch so probiert dass ich sie als Umgebungsvariable von außen steuern konnte. Hat sich aber nicht bewährt. Erstens ist dann der Debug-Code ständig im Code, und zweitens erbt unter Windows jedes Programm sein Environment von seinem Vorgänger, unter Lazarus war das stets Lazarus, um also umzuschalten musste ich Lazarus neu starten. Lästig. Immerhin hatte es aber den Charme, notfalls auch Debug-Infos von einem enfernten Kunden anfordern zu können.

Mein Ziel wäre, dass das Umschalten des Build-Mode links oben im Toolbar zwischen "Debug" und "Release" das miterledigt, das fände ich maximal intuitiv. Für mich (95% WIndows, 4% Linux, 1% MacOS) habe ich im Moment das Gefühl, meine optimale Lösung gefunden zu haben. Ich verwende sie mal für die nächste Zeit, mal sehen ob ich sie danach auch noch so gut finde.

Abschließend die Gewissensfrage: als ich mich gewundert habe, wieso die Debug-Infos unter WIndows nirgends angezeigt werden, und nachdem ich eine Weile vergeblich nach einem Ausgabefenster in der IDE gesucht hatte, ich meinte das hätte es mal gegeben [inzwischen bin ich fast sicher dass das noch zu Zeiten von Delphi RAD Studio war ...], und nachdem ich mt der Dok zu LazLogger erst mal nichts anfangen konnte (Warum soll ich "Win32 GUI Application" bei einer GUI Applikation deaktivieren?) klappt es nun, und ich habe gleich mehrere Wege.

Der der mir persönlich vermutlich am besten liegt:

Code: Alles auswählen

{$IFOPT D+}
        {$AppType CONSOLE}
{$ENDIF}
 
 ...
 
   {$IFOPT D+}writeln(Format({$I %CURRENTROUTINE%} + ': %s',['Program start']));{$ENDIF}
 

wobei ich mir die lange Zeile auf ein Code-Template #d[Tab] gelegt habe. Das müsste auf den Plattformen, für die ich mich interessiere, eigentlich überall und auf Anhieb funktionieren, oder?

Mir gefällts so bisher am Besten, und ich frage mich, ob ich es ins Wiki schreiben soll, damit der nächste Einsteiger nicht wieder x Stunden verbraten muss bis er draufkommt, dass das Ausknipsen von "Win32 GUI Application" nicht bedeutet, dass man die GUI verliert, ganz abgesehen davon dass das Definieren des Release- und Build Modes auch so seine Tücken hat, zumal man das dann bei jedem Projekt nochmal machen muss.

Wiki oder nicht? Was meint ihr?

P.S. Danke für die Infos zu *nix!

Armin.

[af0815]

Problemchen: ich habe jedes Mal wieder vergessen, wo ich die Variable setzen muss. Ich habs schon wieder vergessen Ich glaub, es war -d[Name] bei den Compiler-Optionen? Jemand der nach mir kommt und sich Lazarus installiert und die Sourcen aus der Versionsverwaltung lädt mus da erst mal draufkommen.

Die -d[Name] sind im Projekt gespeichert und es hindert dich niemand, das ganze in der Hauptunit auch zu dokumentieren. Zusätzlich deaktviere ich einen Schalter in der Konfiguartzion anstatt den zu löschen
-dIchTuWas
und
-dxxIchTuWas

damit kann man immer sehen welche Schalter es gibt und welche davon aktiv sind. Und wenn die Liste zu lang ist, so muss man sich sowieso überlegen was man falsch gemacht hat

[corpsman]

Zum Meine Projekte configurieren nutze ich auch gern .inc Dateien, die sammeln dann alle defines und switches

[Nimral]

Okay, ich seh schon, ich bin ziemlich alleine mit meiner Begeisterung

Ich beschränke mich also darauf, den Text im Wiki ein bisschen klarer zu formulieren

Mal wieder herzlichen Dank für eure Zeit,

Armin.

[PascalDragon]

Ich kann Dir nicht bis ganz zum Ende folgen

weil er zum Beispiel keine Debug Informationen für ein System generieren kann

das interpretiere ich mal so, dass das nur zutrifft, wenn der FPC Compiler das Erstellen von Debug-Infos für eine bestimmte *Plattform* überhaupt nicht unterstützt? Anders gesagt, es kann nicht sein, dass der Compiler für ein bestimmtes Projekt WIndows oder Linux Debug-Infos erzeugen kann, und für ein Anderes ncht? Das trifft eher zu für die vielen exotischen Plattformen auf denen FPC auch verfügbar ist, die aber eventuell keinen Debugger untersttzen?

Es hängt nicht nur von der Platform, sondern auch vom verwendeten Assembler ab (der mit -A... eingestellt werden kann). Hier kann es eventuell sein, dass einer das Generieren von Debuginformationen nicht unterstützt.

Das mit der Variable hatte ich auch eine Weile so gemacht, ich habe sie idR DEBUG genannt,

Problemchen: ich habe jedes Mal wieder vergessen, wo ich die Variable setzen muss. Ich habs schon wieder vergessen Ich glaub, es war -d[Name] bei den Compiler-Optionen? Jemand der nach mir kommt und sich Lazarus installiert und die Sourcen aus der Versionsverwaltung lädt mus da erst mal draufkommen.

Wie andere bereits gesagt haben: entweder als deaktiviert hinterlegen (z.B. -dNDEBUG), das mach ich zum Beispiel auch bei Visual Studio bei uns in der Arbeit, oder gleich zwei Buildmodi anlegen (einmal Release und einmal Debug).

Mein Ziel wäre, dass das Umschalten des Build-Mode links oben im Toolbar zwischen "Debug" und "Release" das miterledigt, das fände ich maximal intuitiv. Für mich (95% WIndows, 4% Linux, 1% MacOS) habe ich im Moment das Gefühl, meine optimale Lösung gefunden zu haben. Ich verwende sie mal für die nächste Zeit, mal sehen ob ich sie danach auch noch so gut finde.

Dann füge doch einfach deinem Debug-Buildmode das -dDEBUG hinzu.

Der der mir persönlich vermutlich am besten liegt:

Code: Alles auswählen

{$IFOPT D+}
        {$AppType CONSOLE}
{$ENDIF}
 
 ...
 
   {$IFOPT D+}writeln(Format({$I %CURRENTROUTINE%} + ': %s',['Program start']));{$ENDIF}
 

wobei ich mir die lange Zeile auf ein Code-Template #d[Tab] gelegt habe. Das müsste auf den Plattformen, für die ich mich interessiere, eigentlich überall und auf Anhieb funktionieren, oder?

Für mich ist das ein klassischer Missbrauch einer separaten Funktionalität. Das hat nichts im Wiki als "gutes Beispiel" verloren.

[Nimral]

Ich vertraue Dir unbesehen und will weder diskutieren noch ein Fass aufmachen. Ich hab beim Wiki was dazugeschrieben, allerdings nur Hinweise wie man unter Windows an das Debug-Fenster kommt. Ich denke, das hilft, weils mir geholfen hätte als ich danach gesucht habe. Wie man dann auf die Konsole schreibt habe ich offen gelassen, und LazLogger + DebugLn wird im Artikel sowieso 100 Mal erwähnt.

Liest Du bitte schnell gegen, ob das was ich unter https://wiki.freepascal.org/LazLogger#Stdout.2FConsole verbrochen habe, Deiner Meinung nach Einsteigern weiterhilft? Ich denke Du hättest auch die Privilegien, auf den "Undo" zu klicken oder etwas Besseres zu schreiben was mehr hilft? Ich hätte überhaupt nichts dagegen. Was immer hilft, ist gut, egal wer es macht.

HG, Armin.