DesignTime-Package debuggen?

[himitsu]

n'abend, aktuell funktioniert mal wieder garnichts.

Normale EXE Debuggen ... kein Problem,
aber DLL und vorallem RuntimePackages nerven nur noch.

Aber ganz speziell die DesignTime-Packages.

Ich hab's bei mir jetzt mal auf einen ganz einfachen Test reduziert.

Hier die Anleitung, welche ich schonmal anfing für Emba zu schreiben.
Funktioniert es so bei euch?

Und mal ganz im Ernst, wer lässt wirklich die DebugDCUs aktiv,
oder debuggt ihr niemals?

Zitat:

create new Package
disable the DebugDCU crap, or leave it on ... whatever, nothing changes ... it's just shittier at debugging
add new Unit
add "Register" procedure

Delphi-Quellcode:

procedure Register;

implementation

procedure Register;
begin
  if GetRTLVersion = 0 then
    ;
end;

save all
install package
set start parameter
* host = $(BDS)\bin\bds.exe
* param = -pDelphi
* path = $(BDS)\bin
set breakpoint in this procedure
and run it [F9]
> it does not stop and i don't see blue dots (in first IDE on left site of code editor)
see if is was loaded > Help > Info ... > Versioninfo > search package
see in debug log > the package was loaded with debug infos

Zitat:

A little more ... the dialog is displayed after installation, after compiling, but also when starting the new IDE,
otherwise everything is the same.

Delphi-Quellcode:

unit Unit1;

interface

procedure Register;

implementation

uses
  Winapi.Windows;

procedure Register;
begin
  MessageBox(0, 'blubb', nil, 0);
end;

end.

Delphi 12.1 Prof ... schonwieder frisch installiert
und 'nen ganz einfaches Windows 11 Pro 23H2, ohne viel drauf.


Mein Problem fing damit an, dass ich mir einen Komponenteneditor schreiben wollte,
der bei ExecuteVerb einen Dialog anzeigen sollte.
Meine TForm hab ich inzwischen auch schon komplett entmistet (kein Code und nur noch paar Comboboxen und Buttons drauf),
aber (vermutlich) beim ShowModal bleibt die IDE hängen und macht nichts mehr, außer Beep, wenn ich versuche das IDE-Fenster anzuklicken.

Per se wäre das so weit OK, bei einem modalen Fenster, aber Dieses ist nunmal nicht sichtbar und lässt sich auch nicht finden.
Der Debugger hilft leider auch nicht, da ich nichts debuggen kann und wenn ich einfach an der Stelle "pausiere" dann seh ich im Stacktrace auch nicht viel, außer einen Eintrag mit meinem Package, aber da eben auch nur den Dateinamen, ohne Unit/Prozedur/Zeile/...

Mit DebugDCUs seh ich aber natürlich die Codestellen von den Exceptions, in den RTL-Units, welche Delphi selber beim Start massenhaft wirft.

[Kas Ob.]

I want to share my experience with older versions like XE8 with something similar that might be relevant or not, just food for thought.

Zitat:

set start parameters
* host = $( BDS )\bin\ bds .exe
* param = -pDelphi
* path = $( BDS )\bin

In my XE8 i don't have what named "path" !!, i have "Working Directory" and "Source Path", so i will assume they renamed "Source Path", in all cases..

If you build and saved new and simple a project les say project1.exe, then it will work fine and debug fine and you can put break points and more importantly you can see symbols being resolved like method names...
Now if you run this project1.exe by Windows Explorer then click choose to attach to process then we have two output:
1) if the project1.dpr is opened in the IDE then symbols will be resolved.
2) If no projects are opened or another project is opened, then the Debugger ignore all TDS info and no symbols will be resolved or shown, the debugger can't recognize the project1.exe and handle it as unknown without any debug info..

This is strange and frustrating, and it is a failure... the debugger had it all in TDSinfo yet it don't try.

Anyways, i just wanted to give you hint about this behavior which very likely to be the case with lost debug info and symbols recognition.

To confirm if this is the case, i suggest to repeat your steps, then use VMMap from https://learn.microsoft.com/en-us/sy...ownloads/vmmap , find your package in memory of the debugged bds process,(yup thee is no search, so sort by details) it will be colored as purple and marked as image, expanding that will see .text and .itext sections and their addresses, use these addresses with in your debugger and browse these memory regions to see if your debugger (the one that debugging) is resolving your package symbols and if it did resolve any to that extent..

Now, back to the paths, i don't know if this will help or not but it might be failing/confusing the opened dpr project with running BDS file instead of loaded package/library, so try to attach the bds.exe instead of loading it, who knows... it might resolve the loaded package project and resolve it, hence allowing you to debug, while losing the starting point, but this can be tweaked or workaround with different hacks, might be later talk for different situation.

[Kas Ob.]

Yes one more thing, the IDE is in capable handle project group the right way, so don't forget to try with single opened project (your package) and don't use project group, see if that help.

[Uwe Raabe]

Das Problem ist schon seit einer Weile bekannt. Eine Lösung dafür gibt es aber offenbar noch nicht.

Regression - Delphi 12 - Unable to debug dynamically loaded packages

[himitsu]

oh neeeee

Wir sind grade eben erst von XE auf 11 umgestiegen.
Und wir nutzen viele DLL und statische Packages.
Anfangs ging dort das Debuggen.
Aber inzwischen auch nicht mehr.
Und ganz pervers ist, dass ein Kollege es geschafft hat, dass immer mit DebugDCUs kompiliert wird. (die Option ist aus und ich vermute verpfuschte Suchpfade)
Auf dem Büro-Notebook konnte ich es so lösen, dass ich die DebugDCUs mit den ReleaseDCUs überschrieben hab, aber das ist auf dem Entwicklungs-Server keine Lösung.

Eigentlich sollte FinalBuilder (MSBuild) das selbe erzeugen, was auch in der IDE erzeugt wird,
aber anfangs ging es eben, aber nun auch wieder nicht. Manchmal geht es, wenn die Packages nochmal in der IDE kompiliert wird,
aber eben auch nur noch auf knapp 50% der Entwicklerrechner ... sonst lassen sich Packages nicht mehr debuggen.




Mein privates Ursprungsproblem wird immer schlimmer und ohne Debuggen weiß ich nur, dass es bis ins ShowModal geht und danach stochere ich im Dunklen.

Das Einfache geht alles,

Delphi-Quellcode:

MessageBox(0, '123', nil, 0);

ShowMessage('123');

UseLatestCommonDialogs := False;
ShowMessage('123');

aber verusche ich es selbst, dann friert die IDE ein.

Delphi-Quellcode:

OptionsDialog := {TOptionsDialog}TForm.Create(Self);
Result := OptionsDialog.ShowModal = mrOk;

Delphi-Quellcode:

OutputDebugString('ShowOptionsDialog:1');
OptionsDialog := {TSerialComPortOptionsDialog}TForm.Create(Self);
try
  OptionsDialog.Caption := 'TestTest123';
  OptionsDialog.Position := poScreenCenter;
  OptionsDialog.ShowInTaskBar := True;
  OutputDebugString('ShowOptionsDialog:2');
  Result := OptionsDialog.ShowModal = mrOk;
  OutputDebugString('ShowOptionsDialog:3');
finally
  OutputDebugString('ShowOptionsDialog:4');
  OptionsDialog.Free;
  OutputDebugString('ShowOptionsDialog:5');
end;
OutputDebugString('ShowOptionsDialog:6');

Dabei macht doch ShowMessage mit UseLatestCommonDialogs=False auch "bloß" TForm.Create + ShowModal?

Delphi-Quellcode:

procedure ShowMessage(const Msg: string);
  procedure ShowMessagePos(const Msg: string; X, Y: Integer);
    function MessageDlgPos(const Msg: string; DlgType: TMsgDlgType; Buttons: TMsgDlgButtons; HelpCtx: Longint; X, Y: Integer): Integer;
      function MessageDlgPosHelp(const Msg: string; DlgType: TMsgDlgType; Buttons: TMsgDlgButtons; HelpCtx: Longint; X, Y: Integer; const HelpFileName: string): Integer;
        {} if ... and UseLatestCommonDialogs then
        {} else
          {} Result := DoMessageDlgPosHelp(CreateMessageDialog(Msg, DlgType, Buttons), HelpCtx, X, Y, HelpFileName);
function CreateMessageDialog(const Msg: string; DlgType: TMsgDlgType; Buttons: TMsgDlgButtons): TForm;
  function CreateMessageDialog(const Msg: string; DlgType: TMsgDlgType; Buttons: TMsgDlgButtons; DefaultButton: TMsgDlgBtn): TForm;
    function CreateMessageDialog(const Msg: string; DlgType: TMsgDlgType; Buttons: TMsgDlgButtons; DefaultButton: TMsgDlgBtn; CustomButtonCaptions: array of string): TForm;
      {} Result := TMessageForm.CreateNew(Application);
function DoMessageDlgPosHelp(MessageDialog: TForm; HelpCtx: Longint; X, Y: Integer; const HelpFileName: string): Integer;
  {} {with do.}Position := poScreenCenter;
  {} Result := {with do.}ShowModal;

[himitsu]

path means the working directory

and source comes from the currently opened project.

Original in a project group,
but the simple test without a project group.

[himitsu]

Zumindest ist jetzt ein Problem gelöst.

Man muß innerhalb der IDE unbedingt Application als Owner für Forms verwenden.
Ich hatte hier meine Komponente genommen, um darüber im OptionsDialog auf deren Einstellungen zuzugreifen.

[himitsu]

Zitat von himitsu:

Ich hatte hier meine Komponente genommen, um darüber im OptionsDialog auf deren Einstellungen zuzugreifen.

Ich verwende sonst eigentlich keine externen und vor allem keine "fremden" Owner,
wenn ICH ja die Speicherverwaltung übernehme, also vor allem beim Try-Finally, wo ich es selbst "gleich" wieder freigebe.

[dummzeuch]

Ich compiliere im Debug Mode immer mit debug DCUs.

(nur, weil du das am Anfang gefragt hattest)

Wenn man aus Versehen irgendwo reinspringt, geht man halt mit Shift+F8 wieder raus. Das ist mir lieber als wenn ich im Debugger gar nicht in die RTL springen kann.

[himitsu]

Ich schalte des eigentlich nur an, wenn ich es brauche.

Wir kompilieren auf Arbeit nahezu alles über den FinalBuilder.
Da hab ich es inzwischen mit Debuginfos, aber in externen TDS ... die werden standardmäßig in eine ZIP verschoben, so dass es normal ohne Debuginfos ist, aber notfalls können wir dann einfach die ZIP auspacken und haben dann mit.

Früher hatten wir die Fremdkomponenten teilweise mit und ohne Debuginfos kompiliert und dann unsere Projekte mit einer Version davon ... zum Aktivieren mußte dann alles mit der anderen Version neu kompiliert werden.