Ich akzeptiere ja viele Dinge als Entwickler wenn es mit einer Software mal nicht so klappt oder etwas klemmt oder ein Fehler schwer zu finden oder zu beheben ist.
Geht einem ja meist selbst so. Was ich aber absolut nicht verstehen und akzeptieren kann ist 0 Kommunikation zum Problem.
Gab ja bisher schon viele Fehler in neuen Delphi-Versionen, die einfach bis zur nächsten Version ausgesessen wurde ohne Kommentar. Aber speziell dieser hier

https://quality.embarcadero.com/browse/RSP-33425

schießt den Vogel ab. Die IDE ist damit nicht benutzbar, gefühlt 50 Neustarts am Tag. Und keine einzige Rückmeldung seitens Embarcadero. Nicht mal ein "wir sind dran" oder "ja, kennen wir". Es muss ja kein "wir wissen woran es liegt" sein. In welcher Blase arbeiten die? Ich weiß es nicht.

So, Frust ist raus, weiter warten

"Kommunikation" ist gut.

Hier einer meiner Fälle:
https://quality.embarcadero.com/browse/RSP-33368
https://www.delphipraxis.net/207137-...entheight.html


Die "Antwort", also Ticket einfach schließen und mit einen coolen Status zu versehen, ist echt saugeil.

vorallem da ich die Lösung (zwei einfache Zeilen Code auch genannt hatte)

Ich könnte da auch einen beitragen:

https://quality.embarcadero.com/browse/RSP-27046

Das war sogar eine bezahlte Support-Anfrage im Rahmen unserer Subscription. Das Problem ist bis heute nicht gelöst.

Zum Glück habe ich eine andere Lösung gefunden, die ohne dotNET-Assemblies auskommt. Ist mir auch lieber so.

Trotzdem ist sowas ein Unding.

im Compilat zur Laufzeit hätte ich mein Problem auch selber lösen können,
aber leider gibt es das Problem bereits im Formdesigner.

Und dort wird nicht die Formklasse verwendet, sondern die Form verwendet so eine generierte Pseudoklasse, so dass man sich da nicht einfach reinhängen kann, obwohl wir unsere Forms vererbt haben. Wobei gerade die Vererbung das Problem ausgelöst hat ... was früher ging, raucht jetzt im neuen Delphi ab, obwohl der VCL-Code gleich/ähnlich aussieht.

Gibt es bei den "anderen" auch solche schwerwiegenden Probleme (VS, Android Studio, XCode)?

Android Studio hatte ich schon länger nicht benutzt,
aber "solche" Probleme hatte ich da nie ... OK, es waren auch wesentlich kleinere unaufwändigere Testprojekte.

Im Android Studio bin ich nur mal drüber gestolpert, dass die generierte Form-XML und die Klasse nicht mehr zusammenpasste, weil ich ein Edit im Formdesigner gelöscht hate, also das Edit in der XML fehlte, auf welches die Klasse aber zugreifen wollte.
Direkt gleich beim ersten Testprojekt, wo ich mir ein Projekte mit paar Demokomponente erstellen ließ.

Da ist Delphi wesentich besser/fehlerunanfälliger, auch wenn es schonmal vorkommt, dass die Deklaration der Form-Klasse zerlegt wird.

Also ich habe diesen Fehler bisher noch nicht gesehen. Nun müsste sich schon mal einer die Zeit nehmen und versuchen heraus zu finden was den Fehler verursacht. Liegt das womöglich an einer der verwendeten Komponenten? Passiert das mit einem Projekt, das ohne diese auskommt, was ich nähmlcih vermute? Der Report hilf hier halt schon nicht weiter und wenn Emba das nicht reproduzieren kann, wird das schwierig für die.

PS. Habe eben gesehen, dass das wohl nur die 64 Bit Kompilierung betrifft. Diese nutzte ich bis anhin nicht und deswegen habe ich eventuell auch den Fehler noch nicht gesehen.

Ich habe mir den Report angeschaut.

Wenn dieses Problem wie von euch beschrieben immer auftritt, dann solltet ihr das doch ohne jegliche Fremdkomponente testen und schauen, ob's ebenfalls abschmiert.

Wenn nicht, dann schrittweise Fremdkomponenten hinzufügen bis die Mayonnaise wieder bricht.

Klar, wenn Embarcadero den Fehlercode aufschlüsseln kann und dann weiss, wo (oder vielleicht wieso) das Problem auftritt, dann wäre es nett, wenn man euch das mitteilen würde.

Aber wenn ihr Fremdkomponenten nutzt und nicht ohne testet, dann ist das einfach ein zu weites Feld...

Zitat von dummzeuch:

Ich könnte da auch einen beitragen:

https://quality.embarcadero.com/browse/RSP-27046

Das war sogar eine bezahlte Support-Anfrage im Rahmen unserer Subscription. Das Problem ist bis heute nicht gelöst.

Zum Glück habe ich eine andere Lösung gefunden, die ohne dotNET-Assemblies auskommt. Ist mir auch lieber so.

Trotzdem ist sowas ein Unding.

Hast du mal während des Importierens mit einer anderen BDS-Instanz die IDE debuggt?
Da kommen ja ein Haufen Exceptions (OLE error) beim Importieren zusammen.

Und da verstehe ich nicht, warum die nicht fähig sind das zu Beheben.
Da muss sich doch in ein, zwei Tagen durch geschicktes Debugging die Fehlerquelle finden lassen.

Viele der Exceptions beim Debuggen der IDE kann/sollte man aber auch ignorieren,
vorallem alles mit "Sanctuary", dem Kopierschutz.