Manchmal hab ich das Gefühl ....

[himitsu]

... ich bin der Einzige, der Neueres ausprobiert,
weil funktioniert irgendwie zu oft nicht wirklich
https://embt.atlassian.net/servicede...tal/1/RSS-1691

... der debuggt,
weil funktioniert oft nicht
https://www.delphipraxis.net/215749-...-debuggen.html
und macht "standardmäßig" keinen Spaß mehr
Ich kenne wirklich niemanden, der auch mit Vorliebe immer gleich die komplette RTL, VCL/FMX und vor allem die System-DCU mitdebuggen will, sondern eigentlich zu 99% doch "nur" den eigenen Code.

CodeInsight/IDEInsight gehen oft nicht, bzw. zeigen nichts an.

Ähhhh ja, das Encoding.
https://embt.atlassian.net/servicede...tal/1/RSS-1228

Recovery speichert oft, aber stellt nicht wieder her. (überschreibt sogar nach dem Neustart das Gesicherte)
https://embt.atlassian.net/servicede...tal/1/RSS-1668

Früher blieb es manchmal ewig hängen, aber so lange es hing, wusste man, dass es noch arbeitet.
Jetzt, vor allem bei der asynchronen CodeCompletion, geht die oft nicht auf und niemand sieht, ob es noch arbeitet
und selbst wenn es aufgeht, dann oft zu spät oder erst nach dem 2 Millionsten Drücken der Strg+Leertaste.

Diese automatischen Klammern beim Codevervollständigen von Funktionen nerven ... wenn danach bereits Code steht, welcher nur geändert werden soll, was will ich dann mit diesen nutzlosen Klammern?

Mir haut es oft ein END; in den Code, wenn ich in Funktionen eine Leerzeile einfügen will, für neuen Code.

Und ganz besonders, wenn ich alles speichern sage, warum speichert es dann nicht alles?
-> Desktop (Haltepunkte, geöffnete Dateien und überwachte Ausdrücke gehen verloren und/oder passen nicht mehr zum Code, wenn die IDE abraucht oder ich sie abschießen muß, weil der Debugger mal wieder verreckt und sich dann die IDE nicht mehr beenden lässt)

...

OK, ich leg mich wohl besser nochmal hin und versuche Delphi 'nen Weilchen zu vergessen.

[Sherlock]

Ich nutze schon lange keine Code completion mehr. Aus den von Dir genannten Gründen, und weil das System es irgendwie immer geschafft hat, nicht das vorzuschlagen was ich gesucht habe.

[Der schöne Günther]

Irgendwie klingt das, als sollte ich gar nicht erst versuchen, von Delphi 10.0 Seattle (2015 oder so) auf eine neuere Version zu wechseln.

Ich hatte ein kleineres Projekt einmal auf Delphi 11 hochgezogen und da ist mir auch schon aufgefallen, dass die Code Completion oft überhaupt nicht mehr geht. Ist das heute immer noch so?

[freimatz]

Zitat von himitsu:

... ich bin der Einzige,
... der debuggt,
weil funktioniert oft nicht

Nein, aber deine Schlussfolgerung ist falsch.
Ich kann mich gerade nicht erinnern wann ich das letzte Mal debugged habe ... letzte Woche?
Weil es funktioniert so gut wie nie. Ich habe mir angewöhnt gleich an den Stellen die mich interessieren ein Logging einzubauen.
Apropos interessieren: EMB interssiert das wohl nicht. Wir haben und auf eigenen Rechnung nun einen MVP engagiert um vielleicht einen Workaround zu finden.

[Sinspin]

Zitat von Der schöne Günther:

Ich hatte ein kleineres Projekt einmal auf Delphi 11 hochgezogen und da ist mir auch schon aufgefallen, dass die Code Completion oft überhaupt nicht mehr geht. Ist das heute immer noch so?

Wir verwenden 11.1, es gibt ein paar blöde Macken, aber in den meißten Fällen ist das Ergebnis brauchbar.

[himitsu]

Zumindestens einen Punkt gibt es, der definitiv gegen die 12.x spricht, so lange es dafür keine Lösung gibt, aber falls man es eigendlich zwingend benötigt.
https://www.delphipraxis.net/215749-...-debuggen.html

Ich hatte die Nacht mehrmals den Fall, dass CodeCompletion zwar auf ging, aber außer "nil" und (ich glaub) "false" garnichts in der Liste stand.

[Sinspin]

Reg dich doch nicht auf!
Das ist von Programmierern für Programmierer. Also betrachte es als Liebesbeweis wenn dir Fehler zur Verfügung gestellt werden.

Ich kann mich noch an Zeiten erinnern wo man ne neue Version erst installiert hat wenn das IDE Fix-Pack dafür da war.
Heute würde man vermutlich verklagt werden wenn man die Fehler selber behebt. So als würde man von seinem Partner dafür bestraft, das man sie/ihn nicht für dessen negative Eigenarten permanent lobt.

[jaenicke]

Zitat von Der schöne Günther:

Ich hatte ein kleineres Projekt einmal auf Delphi 11 hochgezogen und da ist mir auch schon aufgefallen, dass die Code Completion oft überhaupt nicht mehr geht. Ist das heute immer noch so?

In kleineren Projekten habe ich das Problem so gut wie nie. In größeren Projekten funktioniert es ab der ersten Unit, die eine Kreuzbeziehung hat, immer schlechter. Wenn man die einzelnen Codeteile sinnvoll trennt (decoupling, Interfaces), keine Kreuzbeziehungen hat, kein with nutzt und keine sehr großen Units verwendet, funktioniert es tatsächlich auch mit Millionen Zeilen an Quelltext recht gut. (Und man hat auch saubereren Quelltext.)

Leider entsprechen die meisten Projekte aber nicht dieser Beschreibung... und dann funktioniert es leider nicht gut. Mit entsprechendem Refactoring lässt sich das gut verbessern, aber das kann je nach Projekt natürlich sehr viel Aufwand sein.

Zitat von freimatz:

Ich kann mich gerade nicht erinnern wann ich das letzte Mal debugged habe ... letzte Woche?
Weil es funktioniert so gut wie nie.

Ich habe vor kurzem ein Projekt mit BPL-Hölle, sprich Packages, gesehen. Da gab es mit dem Debugger viele Probleme. Und das habe ich auch von anderen schon gehört. Packages setze ich abseits von Komponenten aber ohnehin sehr ungern ein, weshalb mich das zum Glück nicht betrifft. Und Projektgruppen sind leider auch nach wie vor ein Problem, die ich aber für Exe plus DLL gerne nutze. Abseits dessen funktioniert der Debugger in meinem Umfeld relativ gut. Manchmal bleibt er einfach hängen, dann kann man nicht mehr fortsetzen und muss die IDE neustarten. Zum Glück passiert das nur selten.

[Uwe Raabe]

Zitat von jaenicke:

Wenn man die einzelnen Codeteile sinnvoll trennt (decoupling, Interfaces), keine Kreuzbeziehungen hat, kein with nutzt und keine sehr großen Units verwendet, funktioniert es tatsächlich auch mit Millionen Zeilen an Quelltext recht gut. (Und man hat auch saubereren Quelltext.)

Bei meinen (aktiven) Delphi-Projekten verfolge ich diesen Ansatz schon seit ein paar Jahren und habe daher kaum Probleme mit Code-Insight & Co. Auf externe Projekte meiner Kunden habe ich leider nur wenig bis gar keinen Einfluss auf dringend notwendiges Refactoring - mit entsprechenden Folgen.

Zitat von jaenicke:

aber das kann je nach Projekt natürlich sehr viel Aufwand sein.

Der Mehraufwand ohne Refactoring summiert sich aber in den Jahren auch auf und führt leicht zu Frustrationen.

Zitat von himitsu:

Zumindestens einen Punkt gibt es, der definitiv gegen die 12.x spricht, so lange es dafür keine Lösung gibt, aber wenn man es eigendlich zwingend benötigt.
https://www.delphipraxis.net/215749-...-debuggen.html

Da meine Packages eh alle auch unter D11 laufen müssen, mache ich das Debugging eben auch in dieser Version.

Da MMX Code Explorer eine DLL ist, funktioniert das Debugging auch in D12.

[himitsu]

Unser stammt teilweise noch aus Turbo Pascal (DOS).

PS, auch im Win32-Compiler selbst verstecken sich immernoch Units, welche aus Zeiten des Turbo Pascal stammen.

Zitat von jaenicke:

Manchmal bleibt er einfach hängen, dann kann man nicht mehr fortsetzen und muss die IDE neustarten. Zum Glück passiert das nur selten.

Blöd dabei ist, dass sich die IDE dann oft nicht beenden lässt, da sie beim Beenden den Debugger beenden will, aber wenn er schon abgekratzt ist, kommt eine Exceptions und das Beenden stoppt.

Unoraktisch ist hier dann, dass der Desktop nicht geseichert wird und dann Haltepunkte usw. im Arsch sind. (vergessen, verschoben, Gelöschte wieder da, ....)