Delphi 12.1 verfügbar/veröffentlicht

[BigAl]

Zitat:

Zitat von himitsu (Beitrag 1535754)

Win64 : ähhh nja neee

Mit F7 in eine eigene Funktion reinspringen zu wollen ... der hält nicht an, so als hätte ich F9 gedrückt.

Das funktioniert hier problemlos... Evtl. ist die Funktion bei Dir "inline". Kannst Du einen Breakpoint in der Funktion setzen?

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1535827)

* Außerdem hat Emba in den letzten Jahrzehnten es nicht geschafft zu reparieren, dass, wenn man sich mit dem Debugger vom Prozess trennt, der Prozess dann NICHT sofort abraucht und wortlos gekillt wird.
* Wozu gibt es dann die Option "Vom Programm trennen", wenn ich auch direkt "Programm beenden" wählen könnte?

Das funktioniert bei mir in aller Regel problemlos, es sei denn vorher war schon ein Fehler im Programm aufgetreten.

[Der schöne Günther]

So kenne ich das auch: Wenn man mitten in einer Exception-Behandlung den Debugger vom Prozess trennt schmiert der Prozess einfach ab.

Kann man bestimmt irgendwie argumentieren, dass das "as designed" ist, halte ich aber auch für einen Defekt.

[himitsu]

Ich kann mich nicht erinnern, dass es jemals wirklich funktioniert hat (mindestens seit XE),
egal ob der Debugger von Anfang an dran hing, oder erst später angehängt wurde.

Es ist auch egal, ob nach einer Exception (aber ja, meistens war vorher eine Exception oder es was im Deadlock ... drum schau ich ja rein)
und ob der Prozess noch in Pause oder mit F9 fortgesetzt wurde.

Entweder ist das Programm sofort weg (meistens und ohne einen Mucks)
oder es raucht kurz danach mit wirren Exceptions ab (selten).



OK, es wäre eh irgendwann abgeraucht, da es die BDS ja hing.

[BigAl]

Zitat:

Zitat von himitsu (Beitrag 1535845)

Ich kann mich nicht erinnern, dass es jemals wirklich funktioniert hat (mindestens seit XE),
egal ob der Debugger von Anfang an dran hing, oder erst später angehängt wurde.

Es ist auch egal, ob nach einer Exception (aber ja, meistens war vorher eine Exception oder es was im Deadlock ... drum schau ich ja rein)
und ob der Prozess noch in Pause oder mit F9 fortgesetzt wurde.

Entweder ist das Programm sofort weg (meistens und ohne einen Mucks)
oder es raucht kurz danach mit wirren Exceptions ab (selten).



OK, es wäre eh irgendwann abgeraucht, da es die BDS ja hing.

Hmmm. Das ist komisch. Den Debugger benutze ich quasi täglich. Bis auf die Sache mit dem Memory leak bei Strings hatte ich da schon ewig keine Probleme mehr. Da läuft soweit alles stabil. Ich wechsel auch teilweise zur Laufzeit der Programme von einem zum anderen Programm. Also Detach / Attach. Das läuft soweit auch alles problemlos. Die IDE legt zwar manchmal ein paar Gedenksekunden ein aber alles ohne Fehlermeldungen etc...

[dummzeuch]

Zitat:

Zitat von himitsu (Beitrag 1535845)

Ich kann mich nicht erinnern, dass es jemals wirklich funktioniert hat (mindestens seit XE),
egal ob der Debugger von Anfang an dran hing, oder erst später angehängt wurde.

Detach funktioniert bei mir mit Delphi 10.2 einwandfrei und auch vorher mit XE2. Zu anderen Versionen kann ich nichts sagen, die verwende ich kaum.

[Uwe Raabe]

Ich benutze das auch ziemlich oft zum Debuggen von IDE-Plugins und Client/Server-Anwendungen - eigentlich ohne Probleme.

[himitsu]

hört auf mich neidisch zu machen :?

Windows 11 mit Delphi 11 ein Delphi 12 debuggen.
Wollte nicht das gleiche Delphi starten, weil es das Projekt ja automatisch beim Start laden würde, welches im kaputten Delphi grade geladen war, damit das Recovery nicht zerstört wird (OK, war am Ende auch egal, weil war eh schon verloren) und ich keine Lust hatte vorher in der Registry rumzufummeln, damit es das nicht lädt.

Mehrere über 4-5 Computer/Schlepptops, mit Windows 7, 10 und 11 und Delphi XE bis 12 ... OK, meißtens versuche ich es garnicht zu trennen und Delphi bleibt dran hängen (falls ich dran denke) ... und wenn ich nicht dran dachte, da war es nahezu immer sofort oder fast sofort abgeraucht ... kann mich nicht erinnern, dass es jemals ging (vielleicht war es auch zu selten und man erinnert sich ja eher an das, was einen stärker nervt)

[TiGü]

Zitat:

Zitat von himitsu (Beitrag 1535856)

hört auf mich neidisch zu machen :?

Windows 11 mit Delphi 11 ein Delphi 12 debuggen.
Wollte nicht das gleiche Delphi starten, weil es das Projekt ja automatisch beim Start laden würde, welches im kaputten Delphi grade geladen war, damit das Recovery nicht zerstört wird (OK, war am Ende auch egal, weil war eh schon verloren) und ich keine Lust hatte vorher in der Registry rumzufummeln, damit es das nicht lädt.

Mehrere über 4-5 Computer/Schlepptops, mit Windows 7, 10 und 11 und Delphi XE bis 12 ... OK, meißtens versuche ich es garnicht zu trennen und Delphi bleibt dran hängen (falls ich dran denke) ... und wenn ich nicht dran dachte, da war es nahezu immer sofort oder fast sofort abgeraucht ... kann mich nicht erinnern, dass es jemals ging (vielleicht war es auch zu selten und man erinnert sich ja eher an das, was einen stärker nervt)

Auf allen 4-5 Computern ist die gleiche Sicherheitslösung installiert?
So Schlangenöl-Antivirus-Gedöns? Obskure Dritt-Firewalls?

Oder dieses Parallel Debugger-Plugin, ursprünglich von Parnassus?
https://blogs.embarcadero.com/de/the...rad-studio-11/
Manche meinen, dass dies die IDE instabil werden lässt.

BTW: Das zweite D12 könntest du auch per neuen Reg-Schlüssel per Verknüpfung starten, dann sollte der nicht automatisch das Projekt laden und wäre praktischerweise gleich nackig ohne Addons.

[BigAl]

Zitat:

Zitat von TiGü (Beitrag 1535867)

Oder dieses Parallel Debugger-Plugin, ursprünglich von Parnassus?
https://blogs.embarcadero.com/de/the...rad-studio-11/
Manche meinen, dass dies die IDE instabil werden lässt.

Auf die Parnassus-Tools (auf alle!) verzichte ich bereits seit mehreren Version. Nicht nur dass diese immer wieder Probleme beim Update der IDE machen (werden nicht sauber deinstalliert), diese erzeugen auch regelmäßig Fehlermeldungen beim Beenden der IDE (zumindest bei meinen Installationen).