Ctrl-# funktioniert nicht (immer)

[Benmik]

Ich bin jedenfalls total dankbar für diese einfache Lösung. Ich wusste nicht, dass dieser Befehl im Kontextmenü ist und habe es daher nie ausprobiert.

Um auf meine Frage zurückzukommen: Bei euch passiert das nicht, dass im Debugger die überwachten Ausdrücke ausgegraut und nicht mehr erreichbar sind?

[himitsu]

F7/F8, da sind die kurz (*1) aus, aber kann mich nicht erinnern, dass die nicht zurück kamen.

*1 wobei das Kurz manchmal echt lang ist.
Schlimm, wenn man zu schnell/oft F7/F8 gedrückt hat, dann bleibt bei mir manchmal der Debugger komplett hängen und reagiert garnicht mehr. Die IDE kann ich dann nur noch abschießen, weil sie beim Beenden dann auch hängen bleibt, egal was ich bei "Debugger läuft noch. Beenden oder Trennen?" auswähle.

[Benmik]

Das sieht so aus und nein, es kommt nicht zurück.

[himitsu]

Blick nach rechts.
Ich frag mich, ob die es irgendwann mal wieder hinbekommen "vernünftige" Standardwerte zu benutzen.

Es ist einfach nur krank, dass seit paar Jahren die DebugDCUs standardmäßig aktiv sind und man ständig in der RTL/VCL landet.

[jaenicke]

Zitat von himitsu:

Es ist einfach nur krank, dass seit paar Jahren die DebugDCUs standardmäßig aktiv sind und man ständig in der RTL/VCL landet.

Das kann man so oder so sehen.

Interessant fände ich eher, wenn man zwar in den Systemunits debuggen könnte, die impliziten Stringumwandlungen davon aber ausnehmen könnte...

Aber das ist hier das falsche Thema.

[TiGü]

Zitat von himitsu:

Es ist einfach nur krank, dass seit paar Jahren die DebugDCUs standardmäßig aktiv sind und man ständig in der RTL/VCL landet.

Hm...ja ja, gewiss...weil man ja auch jeden Tag fünf neue, produktive Projekte anfängt!

Ich bin hingegen immer schwer genervt, wenn die Kollegen das Ausschalten und die DPROJ commiten, weil in 7 von 10 Fällen man nur über den vollständig debuggbaren Callstack zum Ziel kommt.

[himitsu]

Ähhhh, Ja?

Ich bastl mir öfters mal kleine Testprojekte, die ich meistens nichtmal speichere (die sind dann nur Minuten, Stunden bis paar Tage in der IDE).

Zitat:

Ich bin hingegen immer schwer genervt, wenn die Kollegen das Ausschalten und die DPROJ commiten, weil in 7 von 10 Fällen man nur über den vollständig debuggbaren Callstack zum Ziel kommt.

Ihr könnt euch ja gern zwei Build-Configs anlegen?

Delphi-Quellcode:

Release
Degug
FullDebug

Delphi-Quellcode:

Release
Degug
Debug_with_DebugDCUs
Debug_without_Eurekalog

Mich interessiert es selten wo genau es in der VCL knallt ... mir reicht es, wenn ich weiß wo es zuletzt in meinem Code abraucht.
Aber wenn man beim Debuggen in den schwachsinnigsten Basisfunktionen/-klassen landet, ist das kein Vorteil.

Oder macht es dir wirklich Spaß, wenn du dauernd in der Systemunit im Assembler landest?
String-Handling, Interface-AddRef, Release ... -> Variablenbehandlung

Ansonsten müsste ich wohl doch endlich mal in meinem Delphi die Debuginfos für System, Classes und Co. loswerden.


Soweit ich mitbekommen hat, war das keine gewollte Verbesserung.
Emba hatte nur nach Umbau der Projektoptionen nichts mehr hinbekommen.
Ansonsten hätte man zumindesten eine Option für das Standardverhalten (alt/neu) integrieren können.

[dummzeuch]

Zitat von himitsu:

Ansonsten müsste ich wohl doch endlich mal in meinem Delphi die Debuginfos für System, Classes und Co. loswerden.

Gibt's da nicht was von Ratio^D^D^D^D^DUwe Raabe?

https://www.uweraabe.de/Blog/2015/05...ive-debugging/