Inoffizielles deutsches Xbase-Forum

Hi,
folgendes Problem. Wenn man Bibliotheken erstellt hat und die in DLL auslagert, dann werden diese ja nicht automatisch im Quelltext mit eingebunden. Also kann man sie beim Debuggen erst "sehen", wenn etwas daraus aufgerufen und durch den Einzelschrittmodus in die WB geladen werden. So weit so gut. Das ist aber blöde, wenn ich keinen Breakpoint oder Altd() darin stehen habe. Hat jemand eine Idee, wie man die PRG ohne sie ins Projekt mit einzubinden direkt mit geöffnet bekommt um dann eine Breakpoint zu setzen zum Debuggen? Wenn sie einmal auf waren, werde sie ja nicht im Projekt mitgespeichert beim Beenden als geöffnet sondern müssen jedesmal wieder neu abgearbeitet werden.

Moin Manfred,

ich behelfe mir damit, das ich den Aufruf der Funktion mit dem Breakpoint versehe. Wenn die dann erstmal im Debugger mit geladen ist, dann kann ich auch in den DLL-Funktionen (alle, nicht nur die aufgerufene) Breakpoints setzen, die angesprungen werden.

Jan

dazu mußt du die Funktion aber erstmal aufgerufen haben. Und wenn Du Pech hast und die Wb schließt und vorher den BP aus versehen oder warum auch immer gelöscht hast, dann klappt das auch nicht mehr. Wenn der BP aus der XPJ Datei verschwunden ist dürfte das nicht mehr klappen. Oder wie meinst Du das?

Jetzt kann ich Dir nicht ganz folgen. Du rufst doch aus der exe heraus eine Funktion in der dll auf. Und genau den Aufruf kannst Du doch mit einem Breakpoint versehen. Bist Du dann erstmal in der dll drin, kannst Du darin Breakpoints setzen ohne Ende wo immer Du die brauchst.

Jan

Ist da nicht ein Schalter beim Debugger, ob man DLL Funktionen anzeigen oder überspringen soll ?
Im Prinzip kann man vor die Funktion der DLL einen breakpoint setzen und dann im Einzelschritt weiter ...

Tja, einer der Gründe, warum ich den XppDbg so liebe: das geht das auch mit den eingebundenen DLLs direkt zum Programmstart ...

@Hubert,
das stimmt, ein Schalter besagt beim Laden von DLL anhalten. den habe ich gesezt, das passiert aber nur direkt am Anfang und dann nicht wieder. Und das nervt, weil er jedesmal hält, wenn die Initi DLL geladen werden.
@Jan,
manche Funktionen werden aus einer Eventschleife heraus aufgerufen über Pushbutton und da gibt es nichts, wo man angreifen kann. Oder aus einem Codeblock heraus, oder sonstwo. Ansonsten wäre das eine Möglichkeit. Dann würde ich aber hier nicht fragen.
@Georg,
bist Du sicher, das er das macht? Wenn ja, erläutere bitte was Du genau meinst, ich kann mich nämlich daran aus alten zeiten nicht mehr erinnern.

nachtrag,
der Schalter bzgl. DLL gilt nur für DLLload().

Manfred hat geschrieben: ↑Mi, 29. Aug 2018 10:36Dann würde ich aber hier nicht fragen.

Doch, manchmal schon. Manchmal steht man halt auf dem Schlauch und sieht den Wald vor lauter Bäumen nicht mehr.

In solchen Fällen, wie Du die jetzt skizziert hast, mach ich das dann teilweise ziemlich brachial: Ich schreib mir eine kleine Dummy-Funktion mit dem Inhalt des Codeblocks, und rufe im Codeblock diese Dummy-Funktion auf. Dann kann ich auch sowas debuggen. Nicht schön aber hilft.

Ansonsten würde ich sagen: Till hat diese Woche Support-Dienst. Einfach mal ihn fragen.

Jan

habe ich schon gemacht, bisher aber ohne Reaktion von der Seite.

Hallo, Manfred -


etwa so:
Die unter W:\User\... gelisteten Programme sind Bestandteil einer selbst erstellten DLL (oder, genauer: mehrere, selbst erstellter DLLs).

stimmt, habe ich nie bemerkt. verdammt. also können die,wenn die wollten

Ähm .... die DLL muss aber auch mit /DEBUG compiliert worden sein !
Sonst fehlen die debug Infos.

Hubert,
daran hätte ich jetzt wirklich nicht gedacht....

haha,
das Problem ist gelöst.
Wenn das Programm den ersten Schritt im Debugger gelaufen ist, dann gibt es 2 Möglichkeiten die eingebundenen PRG zu sehen.
1) SHIFT+ALT+6
oder
2) Ansicht Debugfenster Module

Jetzt sieht man die PRG und kann sie anklicken und sie werden direkt in die WB geladen...
Das sieht jetzt erstmal gut aus. Mal sehen, was sich tut.

Interessant. Danke für die Hinweise. Das muß ich mir mal merken.

Jan

Ganz so einfach scheint es aber nicht zu sein. hat es jemand schonmal versucht?
Ich habe es so probiert.
Programm gestartet und dann direkt die Module anzeigen lassen nach den ersten Debugschritten. In dem fenster ein Modul angeklickt, damit es geöffnet wird und dann einen Breakpoint gesetzt, wo ich als nächstes landen werde und halten möchte. Das klappt nicht. Es ist sogar so, das sich die WB aufhängt, wenn ich nach dem Breakpoint setzen weiter mache. Das habe ich 2x mindestens reproduzieren können. Ob es Zufall ist? Keine Ahnung, ich teste noch. Aber so, wie ich es mir vorstelle, scheint es nicht zu klappen.

Was die Frage aufwirft:

brandelh hat geschrieben: ↑Mi, 29. Aug 2018 13:43 Ähm .... die DLL muss aber auch mit /DEBUG compiliert worden sein !
Sonst fehlen die debug Infos.

Viele Grüße,
Martin

Hallo, Martin -


zumindest mit dem XppDbg kann ich kein Modul öffnen, das nicht mit /Debug compiliert wurde. Dann fehlen nämlich die Informationen über Zeilennummern etc. Ich gehe aber mal davon aus, dass Manfred das richtig gemacht hat.

@Manfred: mal mit XppDbg versucht? Geiles Teil!

Georg,
das stimmt, aber Xppdbg kann nicht Mousover und anzeigen was gerade angesagt ist als Tooltip. Und evtl. noch viel andere Dinge nicht, an die ich mich in der WB gewöhnt habe.

Hallo, Manfred -


wenn es nur um ein Problem in einer Deiner DLLs geht, kann man auch mal für ein, zwei Läufe den XppDbg verwenden. Du darfst danach ja wieder zur WB greifen. bestimmt!

wenn es nur um ein Problem in einer Deiner DLLs geht, kann man auch mal für ein, zwei Läufe den XppDbg verwenden. Du darfst danach ja wieder zur WB greifen. bestimmt!

Dann kann er auch gleich das DLL-Projekt mit den Prgs laden, Breakpoints setzen und laufen lassen

Hallo, Wolfgang -


so, wie sich Manfred ausdrückt, geht das eben nicht: viewtopic.php?f=15&t=10668#p124732

Daher mein Rat, diesen Teil einfach mal mit dem Standard-Debugger zu untersuchen.