Programm-Absturz seit Delphi 11.2

[rwalper]

Bei uns gibt es das gleiche Problem, unter 11.1 läuft die 32-bit und 64-bit-Anwendung einwandfrei, unter 11.2 crashed nur die 64-bit-App beim Laden der DFM des Hauptformulars, allerdings mit einer anderen Fehlermeldung (ClientHandle nicht gültig oder so) Wir haben alles auf 11.1 zurückgedreht, wir haben aktuell leider keine Zeit, uns damit aufzuhalten.

Wir nutzen DevXpress-Ribbon und -Backstagepanel im Hauptformular und hatten diese Komponenten im Verdacht. Ich habe nun eine leere MDI-Applikation erstellt mit eben diesem Ribbon und dem Backstagepanel und hatte gehofft, dass sich der Fehler nachvollziehen lässt, leider nein:(

So warte nun auf das nächste Update von Emba und DevExpress in der Hoffnung, dass es dann läuft:roll:

[Uwe Raabe]

Zitat:

Zitat von rwalper (Beitrag 1512981)

So warte nun auf das nächste Update von Emba und DevExpress in der Hoffnung, dass es dann läuft:roll:

Wenn kein Bug gemeldet wird, kann auch kein Bug behoben werden. Weder von Embarcadero noch von DevExpress. Man kann ja auch nicht völlig ausschließen, dass der Fehler vielleicht in eurem eigenen Code liegt. Dann nutzt warten rein gar nichts.

[jaenicke]

Zitat:

Zitat von rwalper (Beitrag 1512981)

allerdings mit einer anderen Fehlermeldung (ClientHandle nicht gültig oder so) Wir haben alles auf 11.1 zurückgedreht, wir haben aktuell leider keine Zeit, uns damit aufzuhalten.

Es wäre ja nun kein großer Zeitaufwand, zumindest den Stacktrace des Fehlers zu dokumentieren und den Fehler zu melden. Wenn dabei nichts herauskommt, kann man ja immer noch schauen, ob und wann man mehr Zeit investieren kann.

Und vielleicht hat ja jemand hier im Forum ein ähnliches Problem oder könnte helfen, so dass auch hier der Stacktrace helfen würde.

[atari1040]

Delphi hat sehr viel gemeinsam mit dem HSV in der 2. Liga. Es gibt immer eine Hand voll Leute, die den großen Mist der gebaut wurde noch verteidigen. Die Qualität von Delphi 11 Alexandria ist und bleibt eine Katastrophe.

[jaenicke]

Zitat:

Zitat von atari1040 (Beitrag 1512984)

Die Qualität von Delphi 11 Alexandria ist und bleibt eine Katastrophe.

Heute werden Bugs aber in vielen Fällen viel schneller als früher behoben. Da hat sich im Vergleich zu früher wirklich viel getan.

Was wirklich gar nicht geht, ist die Qualität der Syntaxergänzung. Die verwendet man nun einmal sehr oft und wenn die nicht geht, wie es seit der Umstellung auf LSP leider oft ist, ist das nicht haltbar.

Wenn ich mir allerdings die Anzahl der Bugmeldungen zu Delphi 11 anschaue, dann kann die Qualität für viele gar nicht so schlimm sein.

[atari1040]

Zitat:

Zitat von jaenicke (Beitrag 1512985)

...

Wenn ich mir allerdings die Anzahl der Bugmeldungen zu Delphi 11 anschaue, dann kann die Qualität für viele gar nicht so schlimm sein.

Vielleicht liegt es daran, dass wir unsere Zeit effektiver nutzen müssen, als ständig Bug Meldungen für Delphi zu erstellen. Man benutzt es einfach nur noch dann, wenn man unbedingt muss. Es gibt ja kaum noch eine IDE, mit der man weniger produktiv ist als mit Delphi. Das Gegenteil ist der Fall.
Ich habe da noch ein Beispiel. Wenn ich ein altes Projekt pflegen muss und es in Delphi 11 lade, friert mir die IDE ein. Ich habe lange gesucht, warum das so ist. Von den vielen verwendeten Komponenten war eine nicht installiert. Vor Delphi 11 hat mir die IDE noch gemeldet, dass ein Package nicht geladen werden konnte. Jetzt friert die IDE einfach ein. Da wird doch seit Monaten überhaupt nicht drauf eingegangen.

[Uwe Raabe]

Zitat:

Zitat von atari1040 (Beitrag 1512984)

Es gibt immer eine Hand voll Leute, die den großen Mist der gebaut wurde noch verteidigen.

Verteidigen ist wohl nicht das richtige Wort. Mithelfen es zu verbessern kommt dem schon eher nahe. Im Gegensatz zum HSV (na ja, bis auf einen marginalen Personenkreis) geht das bei Delphi schon, wenn man es möchte.

Ich arbeite gezwungenermaßen mit unterschiedlichen Delphi-Versionen für verschiedene Projekte und muss da immer wieder feststellen, wie mir so manches Feature der neueren Versionen plötzlich fehlt. Natürlich nerven mich auch die bestehenden Bugs, in vielen Fällen wohl auch schon eine Weile länger als so manchen hier. Nur, lamentieren und/oder abwarten tragen rein gar nichts zur Lösung des Problems bei.

Dabei bleibt in diesem Fall immer noch die Frage, ob das Problem wirklich in Delphi selbst liegt, oder ob vielleicht eine sinnvolle und wünschenswerte Änderung (z.B. ASLR) in der letzten Version lediglich die Schwachstellen in anderem Code sichtbar macht.

[atari1040]

Zitat:

Zitat von Uwe Raabe (Beitrag 1512987)

Dabei bleibt in diesem Fall immer noch die Frage, ob das Problem wirklich in Delphi selbst liegt, oder ob vielleicht eine sinnvolle und wünschenswerte Änderung (z.B. ASLR) in der letzten Version lediglich die Schwachstellen in anderem Code sichtbar macht.

Wenn Delphi Schwachstellen aufdeckt kann ich gut damit leben. Wenn eine IDE einfriert und ich nicht mal eine Fehlermeldung bekomme kann ich weniger gut damit leben. Antworten wie "passiert bei mir nicht" sind da immer weniger hilfreich. Es passiert uns ja auch, dass Anwender einen Fehler melden, den wir nicht nachvollziehen können. Da antwortet man am besten nicht, dass es auf dem Entwickler-PC nicht passiert sondern geht mit dem Anwender, der bestimmt zu Recht den Fehler meldet, in die Analyse. Delphi zu verbessern? Ich glaube das ist so unmöglich wie das der HSV Deutscher Meister wird.

[Uwe Raabe]

Zitat:

Zitat von atari1040 (Beitrag 1512988)

Es passiert uns ja auch, dass Anwender einen Fehler melden, den wir nicht nachvollziehen können.

Immerhin meldet der Anwender den Fehler! Was wäre, wenn der Anwender statt dessen euer Programm (oder die neue Version) nicht nutzt und stattdessen in öffentlichen Foren über die miserable Qualität wettert und das Programm als totalen Mist bezeichnet?

Ich will hier ja gar nicht die vorhandenen Fehler klein reden, aber wenigstens den ersten Schritt tun und den Fehler melden und, falls nötig, mit dem Hersteller oder hier im Forum daran arbeiten, ihn zu reproduzieren sollte man erwarten können. Eine Rückmeldung "passiert hier nicht" ist nur eine anderen Formulierung für "es fehlen noch weitere Informationen um den Fehler zu reproduzieren". Das kann manchmal schwierig werden, ist aber für die Behebung notwendig. Wie schon gesagt, beim HSV kannst du vermutlich nichts tun, bei Delphi aber schon.

[atari1040]

Zitat:

Zitat von Uwe Raabe (Beitrag 1512989)

...

Ich will hier ja gar nicht die vorhandenen Fehler klein reden, aber wenigstens den ersten Schritt tun und den Fehler melden und, falls nötig, mit dem Hersteller oder hier im Forum daran arbeiten, ihn zu reproduzieren sollte man erwarten können. Eine Rückmeldung "passiert hier nicht" ist nur eine anderen Formulierung für "es fehlen noch weitere Informationen um den Fehler zu reproduzieren". Das kann manchmal schwierig werden, ist aber für die Behebung notwendig. Wie schon gesagt, beim HSV kannst du vermutlich nichts tun, bei Delphi aber schon.

Uwe, dass hört sich alles schön an was Du schreibst und Du wirst bestimmt viel Beifall dafür bekommen. In diesem Fall treffe ich aber die Entscheidung, was ich in meiner Arbeitszeit mache. Produktiv für den Kunden sein oder ehrenamtlich dem Delphi Hersteller beim Versuch helfen, eine stabile IDE zu entwickeln. Woher weisst Du, wieviele Fehler ich in den letzten Jahrzehnten gemeldet habe? Mein größtes Problem mit Delphi ist die Laufzeit der Fehlerbehebung, die vielleicht sogar kommerzielle Gründe hat. Man fühlt sich schon wie in einer Abo Falle. Dein Fehler wird behoben, wenn Du verlängerst. Seit Delphi 11 draussen ist friert die IDE ein, wenn Du alte Projekte laden möchtest und eine Komponente nicht installiert ist. Die Frage ist dann, welche Komponente, denn darüber schweigt sich die eingefrorene IDE aus. Nein Uwe, zum Glück treffen wir die Entscheidung, welche Entwicklungsumgebung wir einsetzen. Dein Ziel, Delphi zu verbessern in allen Ehren aber mein Ziel kann nach den gemachten Erfahrungen nur noch die Umstellung aller Projekte auf eine andere Architektur sein. Bis dahin muss ich mich wohl mit den Problemen quälen.