Delphi 12.1 verfügbar/veröffentlicht

[Borni]

[QUOTE=Nathan;1535503]

Zitat von omnibrain:

... 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 von 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?

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 von Uwe Raabe:

Zitat von omnibrain:

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 von himitsu:

Nach dem Ende des Debugens ... jedes Mal.

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

[BigAl]

Zitat von himitsu:

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?