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:

Zitat von himitsu (Beitrag 1540515)

... 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:

Zitat von Der schöne Günther (Beitrag 1540530)

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.:zwinker:

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:

Zitat von Der schöne Günther (Beitrag 1540530)

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:

Zitat von freimatz (Beitrag 1540531)

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:

Zitat von jaenicke (Beitrag 1540543)

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:

Zitat von jaenicke (Beitrag 1540543)

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:

Zitat von himitsu (Beitrag 1540534)

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:

Zitat von jaenicke (Beitrag 1540543)

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, ....)

[dummzeuch]

Zitat:

Zitat von himitsu (Beitrag 1540515)

... ich bin der Einzige, der Neueres ausprobiert,
weil funktioniert irgendwie zu oft nicht wirklich :(

Diese Probleme habe ich kaum, weil ich nach meinen schlechten Erfahrungen mit Delphi 12 weiter 10.2 verwende (offensichtlich mit Ausnahme von GExperts und anderen Plugins). Das ist mit allen Updates recht brauchbar und Code Insight funktioniert meistens. Das blöde dabei ist dass ich (bzw. mein Arbeitgeber) so viel Geld dafür bezahlen, auf dem neuesten Stand zu sein, nur um bei jeder neuen Version erneut festzustellen, dass sie nicht brauchbar ist. (wobei 12.1 immerhin besser ist als es 11.x jemals war). Ich überlege jedes Mal, wenn die Verlängerung ansteht, ob wir den Wartungsvertrag nicht einfach auslaufen lassen sollen.

(Das ist übrignes auch der Grund dafür, dass GExperts Bugfixes für Delphi 12 so lange brauchen. Ich habe schlicht kaum persönliches Interesse daran. Gut dass es bei Achim anders aussieht.)

[blawen]

Zitat:

Zitat von dummzeuch (Beitrag 1540553)

(wobei 12.1 immerhin besser ist als es 11.x jemals war)

12.2 steht vermutlich in ein paar Tagen an, zumindest ist für nächste Woche ein Webinar angekündigt und bisher war der Erscheinungstermin ja jeweils fast zeitgleich.
Pers. habe ich mit 12.1 eigentlich gute Erfahrungen gemacht und ich vermute mal, dass am ganzen LSP Gedöns nochmals kräftig gearbeitet wurde. Viele Probleme hängen ja damit zusammen.

[himitsu]

Das fällt mir grad ein, dass ich des mal melden sollte, der LSP-NeustartCodeWeilDerDreckStändigAbstürtz, verhindert jetzt ein WindowsUpdate, wenn was noch nicht gespeichert wurde, dann will Windows das Delphi beenden, aber das startet sich immer wieder neu und bringt eine Fehlermeldung, welche verhindert, dass man den Neustart Runterfahrversuch abbrechen kann, weil es immer wieder sofort wiederkommt, wenn man es wegklickt und dadurch der Abbrechenknopf des Windows-Shutdown nicht gedrückt werden kann.

Inzwischen haben die ja in der 12 das LSP-Neustarten ins Tools-Menü eingefügt.
Haben die uns einfach ohne zu fragen die Idee geklaut.

Ja, einmal half es auch schon, den neu zu starten, als mal wieder absolut nichts ging (ErrorInsight, CodeInsight usw.)


Krank ist auch, dass die Insight-Edits keinen Cursor/Fokus zeigen.

[himitsu]

joar, einfach nur den LSP neu gestartet und schon war wieder mehr drin.

[Uwe Raabe]

Zitat:

Zitat von blawen (Beitrag 1540555)

12.2 steht vermutlich in ein paar Tagen an, zumindest ist für nächste Woche ein Webinar angekündigt

Dazu gibt es am 19. September auch noch ein Webinar auf Deutsch: Die Neuerungen von RAD Studio 12.2 Athens

[fisipjm]

Da würde ich mich gern mit rein Hängen. Wir entwickeln für den Mobil Bereich und durften beim Deploy der APP feststellen, dass es in der mit Delphi 12.1 ausgelieferten Version von Skia wohl einen Bug gibt, der bei Samsung Geräten dazu führt das die APP einfach unvorhergesehen abstürzt. Update von SKIA auf das aktuelle Package gemacht, geht wieder.

Das Lässt mich auch darauf schließen, dass so gut wie kein Delphi Entwickler direkt die neuen Funktionen nutzt oder irgendwie größere Projekte damit am laufen hat. Gab kein RSP dazu, hab selbst aber auch keins angelegt. Meine Erfahrung mit den RSPs, kannst du den Fehler nicht haarklein vorkauen wird sich erst gar keine Mühe gegeben was zu finden. Da das Debugging mit SKIA absolut nicht möglich ist, hab ich erst gar nicht versucht.:|

[Der schöne Günther]

Zitat:

Zitat von fisipjm (Beitrag 1540584)

Das Lässt mich auch darauf schließen, dass so gut wie kein Delphi Entwickler direkt die neuen Funktionen nutzt oder irgendwie größere Projekte damit am laufen hat.

Das habe ich mir wirklich schnell abgewöhnt.

Zu oft gebissen worden, selbst in absoluten Basics wie "Ab XE7 kannst du jetzt Arrays mit dem Plus-Zeichen konkatenieren".
Ich habe immer lieber ein paar Monate gewartet, und, wenn Bedarf, dann vorsichtig ausprobiert.

Einzige Ausnahme, was auf von den neuen Dingen, auf Anhieb wirklich gut geklappt hat, war der WebView2-Wrapper für TWebBrowser, das muss ich ganz ehrlich sagen. Und, zumindest für ein kleineres Projekt, die HighDPI-Unterstützung, das ging auch besser als erwartet.

Sonst lasse ich in der Delphi-Welt lieber die Finger von neuen Dingen, soweit ich sie nicht wirklich brauche, oder es nicht schon eine etablierte Open Source-Bibliothek dafür gibt.

[fred.ahrens]

Bei uns ist die Codevervollständigung und auch Navigation bedeutend schneller und stabiler geworden, als wir konsequent alle Suchpfade zu 3rd-Party-Komponentenquelltexten entfernt haben. Fast alle Komponenten und andere 3rd-Party-Units sind aus LSP-Sicht nur noch als DCU sichtbar und werden ignoriert. Die entsprechenden Suchpfade zu den Quellen werden nur noch dann aktiviert, wenn wir dort einen Fehler vermuten - am Ende ist es meistens aber doch ein Fehler in unserem Code.