Delphi 12.1 verfügbar/veröffentlicht

[TurboMagic]

Zitat:

Zitat von dummzeuch (Beitrag 1535454)

Zitat:

Zitat von Uwe Raabe (Beitrag 1535445)

Wenn man es auch nicht ausdrücklich sagt, bleiben auch alle Fremdkomponenten erhalten - bis auf die über GetIt installierten. Diese werden bei der automatischen Deinstallation entfernt.

Sag bloß, das ist "working as designed"?
Das macht GetIt ja noch schlimmer als unbrauchbar, denn es zerstört aktiv die Installation.

Da das "Ersatz QP" ja jetzt verfügbar ist, darfst du gerne einen Feature Request erstellen.
Meinen Segen hast du dafür... ;-)

Grüße
TurboMagic

[himitsu]

Delphi abends starten, kein Projekt laden, eine Nacht drüber schlafen, morgens wieder beenden und schon knallt dir eine Exception um die Ohren. :thumb:

[DaCoda]

Ich bin ja schon mal froh, das man nicht auch noch Windows neu installieren muss bei einem Wechsel von Rad-Studio 12 auf 12.1 :-)

Also so richtig zeitgemäß ist diese Art von "Update"/"Upgrade" eher nicht...

[scrat1979]

Zitat:

Zitat von Uwe Raabe (Beitrag 1535445)

Nebenbei: Bei den Konopka Komponenten verwende ich GetIt nur um an die Dateien zu kommen. Diese kopiere ich mir, entferne die Installation wieder aus GetIt und installiere die Komponenten manuell. So ist ein Delphi Minor Update trotz Deinstallation nicht mehr als ein Spaziergang.

So mache ich das bei mir i.d.R. auch :-)

[omnibrain]

Zitat:

Zitat von Uwe Raabe (Beitrag 1535391)

Zitat:

Zitat von omnibrain (Beitrag 1535390)

Hat jemand schon DDevExtensions, GExperts und MMX Code Explorer ausprobiert?

Zumindest MMX Code Explorer zeigt bislang noch keine Auffälligkeiten. Für die anderen kann ich nicht sprechen.

Ich habe ihn jetzt in ein frisches Delphi 12.1 installiert. Beim ersten Start kam eine Fehlermeldung, seitdem allerdings nicht mehr.

[Uwe Raabe]

Zitat:

Zitat von omnibrain (Beitrag 1535492)

Beim ersten Start kam eine Fehlermeldung, seitdem allerdings nicht mehr.

Welche genau weißt du wohl nicht mehr?

[omnibrain]

Zitat:

Zitat von Uwe Raabe (Beitrag 1535494)

Zitat:

Zitat von omnibrain (Beitrag 1535492)

Beim ersten Start kam eine Fehlermeldung, seitdem allerdings nicht mehr.

Welche genau weißt du wohl nicht mehr?

Leider nicht, das hätte ich geschrieben. :( Irgendwas wurde nicht gefunden. Kann also durchaus eine "first start" Geschichte sein.

[Nathan]

Zitat:

Zitat von omnibrain (Beitrag 1535390)

Hat jemand schon DDevExtensions, GExperts und MMX Code Explorer ausprobiert?

Hatte dies auch jemand. Arbeite derzeit noch mit DevExpress Version 23.2.3. Delphi 12.0 kein Problem, aber mit 12.1 bekomme ich unter 64 Bit folgenden Fehler:

Cannot compile dxRichEditControlCoreRS29.dpk
Compiler: C:\Program Files (x86)\Embarcadero\Studio\23.0\Bin\dcc64.exe
Embarcadero Delphi for Win64 compiler version 36.0
Copyright (c) 1983,2024 Embarcadero Technologies, Inc.
dxRichEditControlCoreRS29.dpk(122) Fehler: E2004 Bezeichner redeklariert: "__init_record_Dxrichedit_rtf"

Hat das auch jemand oder muss ich einfach DevExpress mit der neusten Version installieren?

[omnibrain]

Zitat:

Zitat von omnibrain (Beitrag 1535390)

Hat jemand schon DDevExtensions, GExperts und MMX Code Explorer ausprobiert?

Inzwischen habe ich Zeit gehabt: DDevExtensions & GExperts habe ich beide selbst kompiliert und kann bis jetzt keine Auffälligkeiten feststellen.
Bei MMX Code Explorer gab es wie weiter oben geschrieben eine einmalige Fehlermeldung.

[bcvs]

Es heißt doch immer, man soll die Installationsart benutzen, also ISO oder Web-Installer, mit der die vorherige Version istalliert wurde.

Aber was ist, wenn man das nicht mehr weiß? Kann ich irgenwie herausfinden, mit welcher Methode mein derzeitiges D 12 installiert wurde? Oder ist das ganze mittlerweile sowieso egal?

[Borni]

[QUOTE=Nathan;1535503]

Zitat:

Zitat von omnibrain (Beitrag 1535390)

... Delphi 12.0 kein Problem, aber mit 12.1 bekomme ich unter 64 Bit folgenden Fehler:

Cannot compile dxRichEditControlCoreRS29.dpk
Compiler: C:\Program Files (x86)\Embarcadero\Studio\23.0\Bin\dcc64.exe
Embarcadero Delphi for Win64 compiler version 36.0
Copyright (c) 1983,2024 Embarcadero Technologies, Inc.
dxRichEditControlCoreRS29.dpk(122) Fehler: E2004 Bezeichner redeklariert: "__init_record_Dxrichedit_rtf"

Hat das auch jemand oder muss ich einfach DevExpress mit der neusten Version installieren?

Das ist ein Fehler bei Devexpress, die arbeiten dran, doppelte Angaben in der DPK https://supportcenter.devexpress.com...-athens-due-to
Unter 12.0 hat der Compiler das noch geschluckt bzw. ignoriert.
Entweder zu fuss ändern oder warten bis der Fehler behoben ist.

[himitsu]

Zitat:

Zitat von bcvs (Beitrag 1535520)

Es heißt doch immer, man soll die Installationsart benutzen, also ISO oder Web-Installer, mit der die vorherige Version istalliert wurde.

Aber was ist, wenn man das nicht mehr weiß? Kann ich irgenwie herausfinden, mit welcher Methode mein derzeitiges D 12 installiert wurde? Oder ist das ganze mittlerweile sowieso egal?

Ja, das hatte ich im aktuellen Installer auch gelesen und ich konnte mich auch nicht mehr erinnern.

Eigentlich sind beide Installer ja die "Selben", nur dass beim OfflineInstaller noch die GOF neben der EXE liegt, wo das GetIt als Offline-Version drin liegt.

Bis vor 'ner Weile wa ja der Offline-Installer noch die alte Version (bei der ursprünglich auch mal Offline und Online die EXE die Selben waren) und wenn es wirklich "inkompatibel" wäre, würde es doch bedeuten, dass im GetIt online und offline Unterschiede drin wären ... warum unterschiedlich und nicht einfach gleich?

[Uwe Raabe]

Fakt ist, dass die ISO lediglich zwei Dateien enthält: Eine radstudio_12_esd_117529a.gof mit den ganzen Dateien und eine radstudio_12_esd_117529a.exe, die aber binär dem Webinstaller RADStudio_12_1_esd_61_7529b.exe entspricht.

[BigAl]

Zitat:

Zitat von Uwe Raabe (Beitrag 1535494)

Zitat:

Zitat von omnibrain (Beitrag 1535492)

Beim ersten Start kam eine Fehlermeldung, seitdem allerdings nicht mehr.

Welche genau weißt du wohl nicht mehr?

Bei mir hat er lediglich - warum auch immer - die FastReport-Komponenten nicht gefunden. Die habe ich dann einfach neu installiert. Das waren allerdings gefühlt 25 Meldungen mit "load next time?". Ich denke das war wohl was ähnliches. Schade, dass da kein Log erstellt wird.

Ansonsten gab's bisher keine Auffälligkeiten.

[bcvs]

Habe es jetzt installiert. Alle Komponenten und alle IDE-Einstellungen wurden übernommen.

[himitsu]

Nach dem Ende des Debugens ... jedes Mal.

Zitat:

Listenindex außerhalb des gültigen Bereichs (10). TComponentList-Bereich ist 0..7.

[6E246208]{rtl290.bpl } System.Classes.TList.Get (Line 5234, "System.Classes.pas" + 2) + $B
[6FB6DFBF]{vcl290.bpl } Vcl.AppEvnts.TMultiCaster.GetAppEvents (Line 686, "Vcl.AppEvnts.pas" + 1) + $B
[6FB6D8E6]{vcl290.bpl } Vcl.AppEvnts.TMultiCaster.DoActivate (Line 438, "Vcl.AppEvnts.pas" + 5) + $9
[6FB12DD0]{vcl290.bpl } Vcl.Forms.TApplication.WndProc (Line 12854, "Vcl.Forms.pas" + 140) + $C
[6E26477C]{rtl290.bpl } System.Classes.StdWndProc (Line 19085, "System.Classes.pas" + 9) + $2
[6FB13927]{vcl290.bpl } Vcl.Forms.TApplication.ProcessMessage (Line 13282, "Vcl.Forms.pas" + 23) + $1
[6FB1396A]{vcl290.bpl } Vcl.Forms.TApplication.HandleMessage (Line 13312, "Vcl.Forms.pas" + 1) + $4
[6FB13CA9]{vcl290.bpl } Vcl.Forms.TApplication.Run (Line 13451, "Vcl.Forms.pas" + 27) + $3
[002B8AD2]{bds.exe } bds.bds + $DE

Irgendwie findet man mehr, was nervt, als was jetzt besser ist.

[freimatz]

Zitat:

Zitat von himitsu (Beitrag 1535736)

Nach dem Ende des Debugens ... jedes Mal.

<SARKASMUS>Ach sei doch froh dass Du (im Gegensatz zu uns) überhaupt debuggen kannst ...</SARKASMUS>

[BigAl]

Zitat:

Zitat von himitsu (Beitrag 1535736)

Nach dem Ende des Debugens ... jedes Mal.

Debugging läuft hier gut (32bit und 64bit). Nur das sich nach dem Debuggen immer "Memory Leak" meldet wenn man strings inspiziert. Das ist aber schon seit ein paar Versionen so und stört mich eigentlich nicht weiter.

[himitsu]

Win64 : ähhh nja neee

Mit F7 in eine eigene Funktion reinspringen zu wollen ... der hält nicht an, so als hätte ich F9 gedrückt.

[himitsu]

Hatte gestern den wohl fiesesten Fehler

* wollte nur Strg+Linksklick machen
* kam so ein Wartedialögchen "lade Datei Winapi.Windows.pas" ... statt den dialog einzubauen, wäre es schöner, das einfach schnell genug zu machen
* und da blieb es dann hängen ... nix ging mehr
* mehrmals rumgeschaut, ob irgendwo ein Dialog/Fehlermeldung offen ist
* * passiert nun ganz gern mal vermehrt, dass Dialoge auf dem falschen Monitor aufgehn
* * manchmal sind sie aber auch nur im Hintergrund, hinter dem eigenen Fenster versteckt, was sich aber nicht minimieren/verkleinern lässt

* nach 'ner viertel Stunde dann angefangen rumzuprobieren und bei Alt+F4 passiert auch was -> das Wartedialögchen verschwand
* aber hing immernoch alles, allerdings Neuzeichnen ging noch (kein "reagiert nicht" vom Windows zu sehn)
* natürlich war auch der __recovery-Ordner leer (was mich nicht wirklich erfreut fröhlich rumhüpfen ließ)

* in der Taskleiste auf "Fenster schließen" wollte Delphi reagieren, aber es knallte immer eine Zugriffsverletzung
* mit Delphi 11 dann das D12 gedebuggt und die Exception kam von dort, wo Delphi den "willst'e Speichern"-Dialog anzeigen wollte
* Fehlermeldung wegklicken und "Fenster schließen" war das Einzige, was noch ging, aber auch immer in der Exception landete


* Außerdem hat Emba in den letzten Jahrzehnten es nicht geschafft zu reparieren, dass, wenn man sich mit dem Debugger vom Prozess trennt, der Prozess dann NICHT sofort abraucht und wortlos gekillt wird.
* Wozu gibt es dann die Option "Vom Programm trennen", wenn ich auch direkt "Programm beenden" wählen könnte?

[BigAl]

Zitat:

Zitat von himitsu (Beitrag 1535754)

Win64 : ähhh nja neee

Mit F7 in eine eigene Funktion reinspringen zu wollen ... der hält nicht an, so als hätte ich F9 gedrückt.

Das funktioniert hier problemlos... Evtl. ist die Funktion bei Dir "inline". Kannst Du einen Breakpoint in der Funktion setzen?

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1535827)

* Außerdem hat Emba in den letzten Jahrzehnten es nicht geschafft zu reparieren, dass, wenn man sich mit dem Debugger vom Prozess trennt, der Prozess dann NICHT sofort abraucht und wortlos gekillt wird.
* Wozu gibt es dann die Option "Vom Programm trennen", wenn ich auch direkt "Programm beenden" wählen könnte?

Das funktioniert bei mir in aller Regel problemlos, es sei denn vorher war schon ein Fehler im Programm aufgetreten.

[Der schöne Günther]

So kenne ich das auch: Wenn man mitten in einer Exception-Behandlung den Debugger vom Prozess trennt schmiert der Prozess einfach ab.

Kann man bestimmt irgendwie argumentieren, dass das "as designed" ist, halte ich aber auch für einen Defekt.

[himitsu]

Ich kann mich nicht erinnern, dass es jemals wirklich funktioniert hat (mindestens seit XE),
egal ob der Debugger von Anfang an dran hing, oder erst später angehängt wurde.

Es ist auch egal, ob nach einer Exception (aber ja, meistens war vorher eine Exception oder es was im Deadlock ... drum schau ich ja rein)
und ob der Prozess noch in Pause oder mit F9 fortgesetzt wurde.

Entweder ist das Programm sofort weg (meistens und ohne einen Mucks)
oder es raucht kurz danach mit wirren Exceptions ab (selten).



OK, es wäre eh irgendwann abgeraucht, da es die BDS ja hing.

[BigAl]

Zitat:

Zitat von himitsu (Beitrag 1535845)

Ich kann mich nicht erinnern, dass es jemals wirklich funktioniert hat (mindestens seit XE),
egal ob der Debugger von Anfang an dran hing, oder erst später angehängt wurde.

Es ist auch egal, ob nach einer Exception (aber ja, meistens war vorher eine Exception oder es was im Deadlock ... drum schau ich ja rein)
und ob der Prozess noch in Pause oder mit F9 fortgesetzt wurde.

Entweder ist das Programm sofort weg (meistens und ohne einen Mucks)
oder es raucht kurz danach mit wirren Exceptions ab (selten).



OK, es wäre eh irgendwann abgeraucht, da es die BDS ja hing.

Hmmm. Das ist komisch. Den Debugger benutze ich quasi täglich. Bis auf die Sache mit dem Memory leak bei Strings hatte ich da schon ewig keine Probleme mehr. Da läuft soweit alles stabil. Ich wechsel auch teilweise zur Laufzeit der Programme von einem zum anderen Programm. Also Detach / Attach. Das läuft soweit auch alles problemlos. Die IDE legt zwar manchmal ein paar Gedenksekunden ein aber alles ohne Fehlermeldungen etc...

[dummzeuch]

Zitat:

Zitat von himitsu (Beitrag 1535845)

Ich kann mich nicht erinnern, dass es jemals wirklich funktioniert hat (mindestens seit XE),
egal ob der Debugger von Anfang an dran hing, oder erst später angehängt wurde.

Detach funktioniert bei mir mit Delphi 10.2 einwandfrei und auch vorher mit XE2. Zu anderen Versionen kann ich nichts sagen, die verwende ich kaum.

[Uwe Raabe]

Ich benutze das auch ziemlich oft zum Debuggen von IDE-Plugins und Client/Server-Anwendungen - eigentlich ohne Probleme.

[himitsu]

hört auf mich neidisch zu machen :?

Windows 11 mit Delphi 11 ein Delphi 12 debuggen.
Wollte nicht das gleiche Delphi starten, weil es das Projekt ja automatisch beim Start laden würde, welches im kaputten Delphi grade geladen war, damit das Recovery nicht zerstört wird (OK, war am Ende auch egal, weil war eh schon verloren) und ich keine Lust hatte vorher in der Registry rumzufummeln, damit es das nicht lädt.

Mehrere über 4-5 Computer/Schlepptops, mit Windows 7, 10 und 11 und Delphi XE bis 12 ... OK, meißtens versuche ich es garnicht zu trennen und Delphi bleibt dran hängen (falls ich dran denke) ... und wenn ich nicht dran dachte, da war es nahezu immer sofort oder fast sofort abgeraucht ... kann mich nicht erinnern, dass es jemals ging (vielleicht war es auch zu selten und man erinnert sich ja eher an das, was einen stärker nervt)

[TiGü]

Zitat:

Zitat von himitsu (Beitrag 1535856)

hört auf mich neidisch zu machen :?

Windows 11 mit Delphi 11 ein Delphi 12 debuggen.
Wollte nicht das gleiche Delphi starten, weil es das Projekt ja automatisch beim Start laden würde, welches im kaputten Delphi grade geladen war, damit das Recovery nicht zerstört wird (OK, war am Ende auch egal, weil war eh schon verloren) und ich keine Lust hatte vorher in der Registry rumzufummeln, damit es das nicht lädt.

Mehrere über 4-5 Computer/Schlepptops, mit Windows 7, 10 und 11 und Delphi XE bis 12 ... OK, meißtens versuche ich es garnicht zu trennen und Delphi bleibt dran hängen (falls ich dran denke) ... und wenn ich nicht dran dachte, da war es nahezu immer sofort oder fast sofort abgeraucht ... kann mich nicht erinnern, dass es jemals ging (vielleicht war es auch zu selten und man erinnert sich ja eher an das, was einen stärker nervt)

Auf allen 4-5 Computern ist die gleiche Sicherheitslösung installiert?
So Schlangenöl-Antivirus-Gedöns? Obskure Dritt-Firewalls?

Oder dieses Parallel Debugger-Plugin, ursprünglich von Parnassus?
https://blogs.embarcadero.com/de/the...rad-studio-11/
Manche meinen, dass dies die IDE instabil werden lässt.

BTW: Das zweite D12 könntest du auch per neuen Reg-Schlüssel per Verknüpfung starten, dann sollte der nicht automatisch das Projekt laden und wäre praktischerweise gleich nackig ohne Addons.

[BigAl]

Zitat:

Zitat von TiGü (Beitrag 1535867)

Oder dieses Parallel Debugger-Plugin, ursprünglich von Parnassus?
https://blogs.embarcadero.com/de/the...rad-studio-11/
Manche meinen, dass dies die IDE instabil werden lässt.

Auf die Parnassus-Tools (auf alle!) verzichte ich bereits seit mehreren Version. Nicht nur dass diese immer wieder Probleme beim Update der IDE machen (werden nicht sauber deinstalliert), diese erzeugen auch regelmäßig Fehlermeldungen beim Beenden der IDE (zumindest bei meinen Installationen).

[Uwe Raabe]

Zitat:

Zitat von TiGü (Beitrag 1535867)

Das zweite D12 könntest du auch per neuen Reg-Schlüssel per Verknüpfung starten, dann sollte der nicht automatisch das Projekt laden und wäre praktischerweise gleich nackig ohne Addons.

Die Option, das letzte geöffnete Projekt automatisch zu laden ist bei mir grundsätzlich ausgeschaltet. Den einen zusätzlichen Klick ist mir die gewonnenen Flexibilität mehr als wert.

Zitat:

Zitat von BigAl (Beitrag 1535868)

Auf die Parnassus-Tools (auf alle!) verzichte ich bereits seit mehreren Version.

Das ist hier auch so. Ich habe vollsten Respekt vor David's Arbeit, aber er hat einfach nicht mehr genug Zeit sich ausreichend darum zu kümmern.

[BigAl]

Eben die Mail bekommen, dass Patch 1 verfügbar ist. Evtl. löst das ja ein paar Problemchen...

[himitsu]

Zitat:

Zitat von BigAl (Beitrag 1535877)

Eben die Mail bekommen, dass Patch 1 verfügbar ist.

https://www.delphipraxis.net/214987-...erfuegbar.html

[himitsu]

Zitat:

Zitat von TiGü (Beitrag 1535867)

Auf allen 4-5 Computern ist die gleiche Sicherheitslösung installiert?
So Schlangenöl-Antivirus-Gedöns? Obskure Dritt-Firewalls?

Oder dieses Parallel Debugger-Plugin, ursprünglich von Parnassus?
https://blogs.embarcadero.com/de/the...rad-studio-11/
Manche meinen, dass dies die IDE instabil werden lässt.

Parnassus kopiert die vorkompilierten Packages blöder Weise in ein globales Verzeichnis, anstatt sie direkt von dort zu registrieren, wo sie runtergeladen wurden,
und dort wird beim Deinstallieren niemals etwas gelöscht und auch den Registry-Eintrag löschen sie nicht.
Letzeres MÜSSTEN sie aber tun und Erstes können sie nicht tun, da sie beim Installieren so einen Mist bauen.

Im Delphi XE und 10.x war Parnassus ja noch garnicht drin
und da ich das Problem schon seit 10-15 Jahren immer mal wieder hatte .... auch im Windows 7 bis 11, Home/Professional/Ultimate und auch im Windows Server (ganz damals noch mit AntiVir und letzterer Server sowieso mit anderem Virenscanner)

[freejay]

Also bei mir klappt "Vom Programm trennen" auch in 95% aller Fälle problemlos... (Delphi 11.3)

[TurboMagic]

Zitat:

Zitat von BigAl (Beitrag 1535868)

Zitat:

Zitat von TiGü (Beitrag 1535867)

Oder dieses Parallel Debugger-Plugin, ursprünglich von Parnassus?
https://blogs.embarcadero.com/de/the...rad-studio-11/
Manche meinen, dass dies die IDE instabil werden lässt.

Auf die Parnassus-Tools (auf alle!) verzichte ich bereits seit mehreren Version. Nicht nur dass diese immer wieder Probleme beim Update der IDE machen (werden nicht sauber deinstalliert), diese erzeugen auch regelmäßig Fehlermeldungen beim Beenden der IDE (zumindest bei meinen Installationen).

Wenn ich richtig weiß, gibt's mittelfristige Pläne das in die IDE zu integrieren, dann wird es bei IDE Änderungen immer gleich mit geändert.
Damit sollte es dann hoffentlich wesentlich stabiler laufen.

[philipp.hofmann]

Erfolgreich auf 12.1 umgestellt (inklusive Patch) und auch schon über eine Woche live damit bei den Kunden unterwegs.
Ganz großer Bonus: Erstmalig das diesjährige Google-SDK-Version-Zwangsdatum schon Monate vorab geschafft und nicht wie bisher immer mit mehreren Wochen Verzug.

Mein größter Wunsch für zukünftige Updates: Gemeinsam mit Indy auf OpenSSL 1.1 (oder höher) umstellen. Für OpenSSL 1.0 wird das Library-Problem (z.B. Libs für MacOS-ARM) immer schwieriger. Ich bin jetzt für OpenSSL auf ICS (kann aber unter MacOS kein SMTP) umgestiegen und für den Mailversand die kostenpflichtige ipWorks SSL-Anbindung umgestiegen.

[Rollo62]

Bei mir läuft D12.1 auch bislang auch sehr gut, den Patch 1 habe ich noch nicht, kommt aber nächste Woche.

Ab dem 01.05. wird es die Zwangsbeglückung mit XCode 15 und iOS 17.4 geben, dann aber leider ohne Debug-Funktion.
Ich warte noch ab bis dahin und teste und versuche soweit wie möglich alles vorzubereiten,
bis ich dann demnächst wohl ohne Debugging auskommen muss.

Zumindest läuft der Andrid Debugger jetzt wieder etwas besser, aber auch nicht immer, und der ist kein Vergleich mit dem iOS Debugging-Erlebnis.
Ich hoffe, dass ich das iOS Debug Problem irgendwie gelöst bekomme, dann w#re ich erstmal rundrum zufrieden.