[Gelöst] Wegweiser gesucht durch die Units und das Debugging

[Nimral]

Hi allseits,

ich versuche gerade, den Aufbau einer LCL Applikation zu erforschen. Weit komme ich da ohne Wegweiser durch euch nicht, die Dokus und Wikis die ich gefunden habe sind nur vage Hinweise ohne viel konkreten Nutzen. Ich suche konkret nach dem Mechanismus der für die äußerste Message-Loop (Application.Run) zuständig ist. Der Sourcecode meines GUI Projekts und die Durchsicht der in den uses eingetragenene Units bringt mich zum "Application" Objekt in forms.pp. Dieses scheint allerdings wieder nur irgendeine Kulisse zu sein, denn die für mich interessanten Prozeduren wie z.B. "Run" (Zeile 1508) werden zwar deklariert, aber die Unit beinhaltet keinerlei Code.

- welcher Mechanismus erlaubt es, den Code für Application.Run woanders zu implementieren, und wie vollziehe ich ihn nach bis ich konkret den Code von "Application.run" gefunden habe?

Ich habe dann versucht, das mit dem Debugger zu lösen, also einfach in Application.run hinein zu steppen um zu sehen wo ich raus komme. Immerhin bekomme ich forms.pp als Codezeile angezeigt, aber das Reinsteppen zum konkreten Code funktioniert nicht. Offenbar versteckt er sich in einem vorkomplilierten Modul (ist das das was ihr "Package" nennt?), ich meinte irgendwo gelesen zu haben dass man die Datei "forms.pp" dem Projekt hinzufügen kann. Mache ich das, kann ich das Projekt nicht mehr kompilieren, es fliegt in der unit controls.pp in der Zeile nach dem "end." (4636) mit einem undokumentierten Fehler 2013121801 auf die Nase. Ich habe wohl wieder ein Monster aufgeweckt.

- ich habe den Source-Code, das ist schon mal genial, aber wie baue ich mein Projekt so, dass ich in die LCL (bzw. andere Units die ich möglicherweise verwende) hinein debuggen kann? Einfach nur die "Debug" Konfiguration zu wählen bzw. den Soucrecode einzelner Dateien zum Projekt hinzufügen scheint es alleine nicht zu bringen?

Armin.

Thnx, Armin

[mschnell]

welcher Mechanismus erlaubt es, den Code für Application.Run woanders zu implementieren

Warum willst Du das ?
-Michael

[wp_xyz]

ch meinte irgendwo gelesen zu haben dass man die Datei "forms.pp" dem Projekt hinzufügen kann. Mache ich das, kann ich das Projekt nicht mehr kompilieren, es fliegt in der unit controls.pp in der Zeile nach dem "end." (4636) mit einem undokumentierten Fehler 2013121801 auf die Nase. Ich habe wohl wieder ein Monster aufgeweckt.

Ja... Mache all diese Änderungen rückgängig, entferne die Compilate dieser Units aus deinen Projekt-Ordnern. Idealerweise hast du ein Projektbackup, bevor du "forms" hinzugefügt hast.

aber wie baue ich mein Projekt so, dass ich in die LCL (bzw. andere Units die ich möglicherweise verwende) hinein debuggen kann?

Du musst die IDE mit Debug-Informationen kompilieren. Gehe dazu nach "Werkzeuge" > "Lazarus kompilieren einrichten", wähle bei "Profil zum Kompilieren" den Eintrag "Debug IDE" aus. Im Feld "Einstellungen" lösche die Option "-gh", sonst erhältst du bei jedem Beenden der IDE eine Meldung über nicht gefundene Speicherlecks - ist nicht schlimm, aber lästig... Dann auf "Neu kompilieren" klicken und warten. Nach einiger Zeit startet Lazarus neu, und du kannst mit dem Debugger auch die eingebauten Units der LCL und von Drittherstellern erreichen.

Aber Achtung. In die Units, die zum FPC gehören (z.B. Objects, SysUtils usw), kommst du immer noch rein. Dafür müsstest du auch FPC mit Debuginformationen kompilieren, was aber aus der IDE heraus nicht vorgesehen ist. Ist ein Abenteuer für sich... In der Regel braucht man das aber nicht und es ist sogar extrem lästig, weil bei jedem Prozedursprung ganz zentrale Routinen aufgerufen werden.

[Nimral]

welcher Mechanismus erlaubt es, den Code für Application.Run woanders zu implementieren

Warum willst Du das ?
-Michael

Technisches Interesse. Es ist nicht OOP (Interface/Inheritance), es ist nicht Conditionals - was ist es denn?

Hauptziel ist Nachvollziehbarkeit von Abhängigkeiten, in plattformübergreifenden Projekten, um im Fall von Unklarheiten bei den "Details" in den Quellcode schauen zu können.

Armin

[Nimral]

Du musst die IDE mit Debug-Informationen kompilieren.

Werd ich sogleich machen, danke! Und ja, ich habe natürlich alle alten Stände immer brav aufbewahrt (Subversion), ich habe einen einfachen Weg zurück. Und rumexperimentiert wird sowieso bevorzugt mit einem kleinen Testprojekt.

Aus technischem Interesse: wieso die IDE neu kompilieren? Die will ich doch nicht debuggen! Eigentlich hätte ich erwartet, dass ich beim Compiler/Linker und meinetwegen auch beim Debugger irgendwas machen muss, was auf das Erstellen und Einbinden von Symboldateien hinaus läuft, aber bei der IDE? Auf die Idee wäre ich freiwillig nicht gekommen, das ist so ziemlich das einzige Tool das ich nicht mit der Debugbarkeit meines Projektcodes in Verbindung gebracht hätte.

Armin.

P.S. Inzwischen habe ich die IDE neu kompiliert, und es klappt tatsächlich genau so wie ich es gehofft habe. Seltsamer Weise stammt der Code für Application.run aus einer Datei "application.inc". Immerhin enden meine Traces aber dann dort wo ich die ganze Zeit drauf gewartet habe: im Widgetset TWin32WidgetSet, ich vermute, auf dem Raspi würde ich in einem anderen Widgetset herauskommen, so werden also die verschiedenen Plattformen abgebildet. Fehlt mir zum verständnis nur nochd er Mechanismus, mit dem die richtige application.inc Datei ins System geschmuggelt wurde. Vielleicht kann Michael Licht ins Dunkel bringen, wie das Ganze zusammenhängt?

[wp_xyz]

wieso die IDE neu kompilieren? Die will ich doch nicht debuggen!

Schon klar (obwohl du das irgendwann auch mal machen wirst). Du musst wissen: Lazarus und FPC unterstützen nur statisches Linken von Packages, d.h. Packages (intere und externe Bibliotheken), werden in die IDE eingebunden, nicht wie bei Delphi über DLLs. Daher ist der einfachste Weg, beim Debuggen in diese Units gelangen zu können, die IDE mit allen Abhängigkeiten mit Debuginformationen neu zu kompilieren.

Alternativ kannst du auch über "Projekt" > "Projekteinstellungen" > "Compilereinstellungen" > "Hinzufügungen und Beeinflussungen" > "Hinzufügen" > "Benutzerdefinierte Option" in der neu auftauchenden Zeile "Custom" einen Compiler-Schalter für Debug-Informationen eintragen - ich verwende in der Regel immer -gw2 (für Dwarf2). Beim nächsten Kompiliervorgang wird dann dein Projekt mit allen verwendeten Packages (LCL und weitere Third-Party, aber nicht mit FCL und RTL) mit Debuginformationen neu kompiliert. Geht etwa schneller als die IDE neu zu bauen, hat aber den Nachteil, dass das relativ oft wiederholt wird, z.B. wenn du zwischendurch ein Projekt lädst, das den Compilerschalter nicht hat.

[Nimral]

Alternativ kannst du auch über "Projekt" > "Projekteinstellungen" > "Compilereinstellungen" > "Hinzufügungen und Beeinflussungen" > "Hinzufügen" > "Benutzerdefinierte Option" in der neu auftauchenden Zeile "Custom" einen Compiler-Schalter für Debug-Informationen eintragen - ich verwende in der Regel immer -gw2 (für Dwarf2).

DAS ist genau das, wonach ich die ganze Zeit gesucht habe Damit ist meine Welt wieder rund - zumindest was Teilfrage 2 (debuggen) betrifft. Danke!

Armin.

[theo]

Fehlt mir zum verständnis nur nochd er Mechanismus, mit dem die richtige application.inc Datei ins System geschmuggelt wurde. Vielleicht kann Michael Licht ins Dunkel bringen, wie das Ganze zusammenhängt?

Das konkrete Interface wird afaik über den Pfad eingebunden:

z.B. lazarus/lcl/interfaces/gtk3/
resp. lazarus/lcl/units/x86_64-linux/gtk3

Dort wird dann wirklich mit der Interface Library kommuniziert.
Z.B. in gtk3object.inc

Code: Alles auswählen

procedure TGtk3WidgetSet.AppProcessMessages;
begin
  {$IFDEF GTK3DEBUGCORE}
  DebugLn('TGtk3WidgetSet.AppProcessMessages');
  {$ENDIF}
  while gtk_events_pending do
    gtk_main_iteration_do(False);
end;

z.B. "gtk_events_pending" ist dann bereits in der GTK3 library.
https://developer.gnome.org/gtk3/stable ... ts-pending

[Nimral]

Das konkrete Interface wird afaik über den Pfad eingebunden:

Ja schon, so funktioniert es offenbar. Nur - wo ist der Mechanismus der genau das macht? Am Beispiel aufgehangen:

- forms.pp war leicht zu finden, darin steckt eine Prozedur "Application.run" - allerdings kein Code. Der steckt in der application.inc Datei, bei mir unter "lcl/win32 (oder so ...)" da ich gerade unter Windows unterwegs bin. Da aber der Typ TApplication korrekt ist, und die Prozedur weder abstract noch override markiert ist, müsste eigentlich bereits der Compiler aussteigen, da die Prozedur zwar deklariert aber nicht implementiert wurde. Schätze konkret, was da abgeht hat mit OOP nichts zu tun. Oder es gibt ein "hidden feature" welches das verstreuen von Objektcode auf mehrere Dateien erlaubt. Oder Forms.pp ist nicht die Datei, aus der meine Applikation das Objekt TApplication wirklich bezieht.

So wie die Verzeichnisstruktur gebaut ist, müsste irgendwo in der Tiefe eine {$I \%xxxx%\applicaton.inc} Direktive versteckt sein, wobei x von der Plattform, für die erstellt werden soll, abhängen müsste. Der Punkt wo ich es erwartet hätte wäre TApplication.Run gewesen, aber da ist entweder nix, oder es gibt woanders eine "überlagerte" TApplication.run prozedur und ich find nicht heraus wo und wie es von da ins Gesamtsystem eingebaut wurde.

Umgekehrt enthält die application.inc Datei in der 1. Zeile eine mir bisher unbekannte Compiler-Direktive:

Code: Alles auswählen

 
{%MainUnit ../forms.pp}
 

... da ist also eine Verbindung - allerdings in die verkehrte Richtung. Aus irgendeinem Grund weiß der Compiler, dass diese Datei die Implementierung der Methoden in forms.pp enthält, und forms.pp weiß aber noch nicht, dass seine Methoden woanders implementiert wurden. Da ist mein missing Link - welcher Mechanismus setzt die beiden zusammen?

Armin.

Ach, sorry, ich blindes Huhn! forms.pp Zeile 2245:

Code: Alles auswählen

 
{$I controlscrollbar.inc}
{$I scrollingwincontrol.inc}
{$I scrollbox.inc}
{$I customdesigncontrol.inc}
{$I customframe.inc}
{$I customform.inc}
{$I customdockform.inc}
{$I monitor.inc}
{$I screen.inc}
{$I application.inc}
{$I applicationproperties.inc}
{$I hintwindow.inc}  
 

und schon ist meine Welt wieder rund!

[Socke]

Ein Tipp: Wenn du den Cursor auf der Methodendeklaration stehen hast, kannst du mit Strg+Umschalt+Pfeil Hoch/Runter direkt zur Implementierung und zurück springen.