RAD-Studio 10.2.2 erschienen

[MEissing]

Kurz zur Info: Es gibt einige Interface-Änderungen, die wir näher untersuchen und wir planen einen Hotfix/Release, um auch alle Fremdherstellerkomponenten (ohne Sourcecode) wieder zum laufen zu bewegen.

[sakura]

Zitat:

Zitat von MEissing (Beitrag 1388825)

Kurz zur Info: Es gibt einige Interface-Änderungen, die wir näher untersuchen und wir planen einen Hotfix/Release, um auch alle Fremdherstellerkomponenten (ohne Sourcecode) wieder zum laufen zu bewegen.

Schaut mal auch nach - keine der letzten DevExpress Versionen lässt sich installieren, wenn RichEdit dabei ist :?

...:cat:...

[blawen]

Zitat:

Zitat von Darlo (Beitrag 1388822)

Kurz zur Info: Die Sourcecode-Version der UniDac's lässt sich unter 10.2.2 compilieren und nutzen.

Dies habe ich auch versucht, allerdings kommt dann immer die Meldung

Zitat:

[dcc32 Fataler Fehler] CRControlsReg.pas(18): E2225 'Never-build' Package 'dac250' muss neu compiliert werden

Wobei mir noch nicht klar ist, was ich genau falsch mache. Hast Du mir/uns ev. einen Tipp?

[Daniel]

Wenn ich den Beitrag von Matthias richtig verstehe (und auch Marco Cantú hatte sich in diese Richtung geäußert), dann macht Ihr erstmal gar nichts falsch. Es scheint, dass es irrtümlicherweise an wenigstens einer Stelle einen sog. "breaking Change" gab, der dafür sorgt, dass bestehende, bereits kompilierte, Packages nicht in jedem Fall weiter verwendet werden können. Eine Lösung dafür soll - siehe oben - von Embarcadero kommen. Sofern man über die Quellocdes der derzeit inkompatiblen Komponente-Packages verfügt, kann man diese auch selbst neu kompilieren. In dem Fall könnte es jedoch passieren, dass nach der Korrektur von Embarcadero besagte Packages erneut übersetzt werden müssen.

Grundsätzlich betrifft dies nicht alle Packages, ich habe hier ein Package mit haus-internen Komponenten, das tadellos weiter funktioniert.

[Sherlock]

Hut ab vor Idera, daß sie so schnell das Problem identifiziert haben! Jetzt noch die Lösung vor Weihnachten und alle sind glücklich :)

Sherlock

[himitsu]

Zitat:

Zitat von Sherlock (Beitrag 1388835)

Hut ab vor Idera, daß sie so schnell das Problem identifiziert haben! Jetzt noch die Lösung vor Weihnachten und alle sind glücklich :)

Gab es da nicht auch viele Betatester?

DevExpress und RichEdits sind ja nicht grade Exoten.

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1388838)

Zitat:

Zitat von Sherlock (Beitrag 1388835)

Hut ab vor Idera, daß sie so schnell das Problem identifiziert haben! Jetzt noch die Lösung vor Weihnachten und alle sind glücklich :)

Gab es da nicht auch viele Betatester?

Für Updates... pardon "Releases" gibt es keine Betas...
Wer braucht sowas auch schon, dann findet man Fehler ja vor dem Kunden, wie unlustig. :twisted:

Eventuell hätte Embarcadero mal einen Entwickler behalten sollen, der weiß, dass Änderungen an generischen Methoden (TArray.Sort<T>/TArray.QuickSort<T>) aufgrund der Compilerarchitektur Interface breaking Changes sind.

[Der schöne Günther]

Nix verstehen. Man darf an der Implementation von TArray.Sort<> nichts ändern weil sonst irgendetwas auseinanderfällt?

[Stevie]

Zitat:

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

Nix verstehen. Man darf an der Implementation von TArray.Sort<> nichts ändern weil sonst irgendetwas auseinanderfällt?

Nicht in einem non interface breaking Release, nein.
Ich wage es sogar, zu vermuten, dass man nichtmal Implementierungen in generische Typen ändern darf - hab es schon zu oft gehabt, dass ich einfach nur eine Methode in einer Spring4D Collection Klasse geändert habe und alle aufbauenden Packages und Module neu builden musste, weil sonst der dämliche F2051 kam.

Aber Generics sind halt #Neuland :mrgreen:

[jbg]

Zitat:

Zitat von Stevie (Beitrag 1388853)

Nicht in einem non interface breaking Release, nein.

Also bei Delphi 2009 Update 2 oder 3, hat Barry Kelly (ich denke das er es war) seinerseits im Compiler einen Hack eingebaut, so dass bereits genutzte Generics beim Linken durch die neue Implementierung ersetzt wurde. Also machbar ist/war es.

Zitat:

Aber Generics sind halt #Neuland :mrgreen:

Wir ärgern uns auch immer wenn eine kleine Änderung an unseren Delphi 2009 Projekten zu internen Compiler Fehlern führt, weil Generics dort so buggy sind. Eigentlich eine Frechheit wie lange es gedauert hat, bis man Generics einigermaßen ordentlich nutzen konnte. Dass nach fast 10 Jahren Generics immernoch ein paar (kleinere) Probleme haben...