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.

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.

Zitat von TiGü:

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.

Nein, habe ich nicht. Aber ich sehe es nicht als meine Aufgabe Bugs in Delphi zu fixen.

Wenn ich das im Rahmen von GExperts für alte Delphi-Versionen mache, ist das eine Sache, aber für die aktuelle Version, für die ich ein Schweinegeld bezahlt habe und auch noch bezahlten Support habe, sollte das anders laufen.

Zitat:

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.

Dachte ich auch. Aber dann kamen zwei Updates und der Fehler ist immernoch da.
Wahrscheinlich benutzen zu wenige Kunden dotNET-Assemblies.

Oder vielleicht funktioneren die auch gar nicht mehr, aber es ist noch niemandem aufgefallen, weil man sie gar nicht mehr importieren kann. :->

Ich bin jedenfalls froh, dass ich eine andere Lösung gefunden habe. Es ging um eine GenICam-Schnittstelle für eine Kamera. Alleine der Gedanke, dass ich mich jetzt neben allen anderen Problemen dabei auch noch mit dotNET-Gedöhns rumschlagen müsste, lässt mich erschauern.

Mein neustes Schmankl ... mal sehn ob sie es diesmal, nach über 10 Jahren, behoben bekommen, die eine Eigenschaft zu deaktivieren.
https://quality.embarcadero.com/browse/RSP-33826 (im alten QC war es ja schon mehrmals gemeldet wurden)

absolut schwachsinnige Transparenz im IDE-Insight