RAD Studio, Delphi, C++Builder 12.2

[himitsu]

Zitat:

Zitat von TurboMagic (Beitrag 1541384)

Es gibt da scheinbar ein Editor Kontext Menü dazu mit diversen Optionen wie
sich den selektierten Codeabschnitt erklären lassen.

Joar, hatte sich dann auch geklärt, als ich die Fotos in der Hilfe fand.
https://docwiki.embarcadero.com/RADS...rt_CodeInsight

Und entspricht dem, was mindestens seit 12.1 schon der ChatGPT-Wizard konnte (zuzüglich ein paar anderer KI-Systeme)
https://www.delphipraxis.net/1540931-post25.html
https://www.delphipraxis.net/1541023-post42.html

Anhang 57090
Anhang 57105

Und zusätzlich, soll es in der OpenToolsAPI auch etwas für geben.

[himitsu]

Per se würde ich die farbigen Debugtexte schön finden, aber es ist einfach nur pervers, wie es gelöst wurde.

Nachträglich die Ausgabe zu färben, kann niemals ein brauchbares Ergebnis liefern.

[MatthiasFehr]

Zitat:

Zitat von MatthiasFehr (Beitrag 1541336)

Zitat:

Zitat von Uwe Raabe (Beitrag 1541321)

Zitat:

Zitat von win568 (Beitrag 1541319)

Wir warten seit Jahren auf die 64 Bit Compilerarchitektur, da unsere Anwendung nicht mehr ohne Absturz der IDE erzeugt werden kann.

Dazu kann ich leider nicht viel sagen, da mir bislang noch kein solches Projekt untergekommen ist. Eure spezielle Anwendung und die damit entstehenden Probleme kenne ich naturgemäß halt auch nicht. Ich vermute allerdings stark, dass auch Embarcadero hier nur Abhilfe schaffen kann, wenn sie die nötigen Informationen bekommen mit denen man das dort nachstellen kann.

Antwort: ich habe ein solches Projekt, dass sich nicht in 64 Bit compilieren lässt, weil der Compiler "zu wenig Speicher" hat. Werde die neue Version damit prüfen - drücken wir die Daumen...

Ergänzung zu Delphi 12.2
Die Fehlermeldung "Delphi 12.2 [dcc64 Fataler Fehler] Zu wenig Arbeitsspeicher" wird weiterhin erzeugt, obwohl der 64 Bit Compiler aktiviert ist.
Der Programmcode hat rund 150.000 Code-Lines...

Frage: könnte es hier andere Probleme geben, die bei Umschalten von 32 Bit auftreten?

[freimatz]

Habe zwar keine Ahnung was die Ursache sein könnte, aber "150.000 Code-Lines" ist doch fast nichts. :stupid:
Oder sind die 150.000 Code-Lines für eine unit?

[win568]

Zitat:

Zitat von MatthiasFehr (Beitrag 1541433)

Zitat:

Zitat von MatthiasFehr (Beitrag 1541336)

Zitat:

Zitat von Uwe Raabe (Beitrag 1541321)

Zitat:

Zitat von win568 (Beitrag 1541319)

Wir warten seit Jahren auf die 64 Bit Compilerarchitektur, da unsere Anwendung nicht mehr ohne Absturz der IDE erzeugt werden kann.

Dazu kann ich leider nicht viel sagen, da mir bislang noch kein solches Projekt untergekommen ist. Eure spezielle Anwendung und die damit entstehenden Probleme kenne ich naturgemäß halt auch nicht. Ich vermute allerdings stark, dass auch Embarcadero hier nur Abhilfe schaffen kann, wenn sie die nötigen Informationen bekommen mit denen man das dort nachstellen kann.

Antwort: ich habe ein solches Projekt, dass sich nicht in 64 Bit compilieren lässt, weil der Compiler "zu wenig Speicher" hat. Werde die neue Version damit prüfen - drücken wir die Daumen...

Ergänzung zu Delphi 12.2
Die Fehlermeldung "Delphi 12.2 [dcc64 Fataler Fehler] Zu wenig Arbeitsspeicher" wird weiterhin erzeugt, obwohl der 64 Bit Compiler aktiviert ist.
Der Programmcode hat rund 150.000 Code-Lines...

Frage: könnte es hier andere Probleme geben, die bei Umschalten von 32 Bit auftreten?

Du musst in den Projekteinstellungen unter Delphi Compiler msBuild aktivieren und dort die Tool Architektur auf 64Bit umstellen. Dann erst wird der 64Bit Binary Compiler verwendet.

[win568]

Gibt es eine neue Möglichkeit, die Zielplattform zu erzwingen ? Wenn ich für ein Projekt die Zielplattform 64 Bit festlege, das Projekt speichere und wieder öffne, dann ist die Plattform auf einmal auf 32 Bit ?

[MatthiasFehr]

Zitat:

Zitat von win568 (Beitrag 1541441)

Zitat:

Zitat von MatthiasFehr (Beitrag 1541433)

Zitat:

Zitat von MatthiasFehr (Beitrag 1541336)

Zitat:

Zitat von Uwe Raabe (Beitrag 1541321)

Zitat:

Zitat von win568 (Beitrag 1541319)

Wir warten seit Jahren auf die 64 Bit Compilerarchitektur, da unsere Anwendung nicht mehr ohne Absturz der IDE erzeugt werden kann.

Dazu kann ich leider nicht viel sagen, da mir bislang noch kein solches Projekt untergekommen ist. Eure spezielle Anwendung und die damit entstehenden Probleme kenne ich naturgemäß halt auch nicht. Ich vermute allerdings stark, dass auch Embarcadero hier nur Abhilfe schaffen kann, wenn sie die nötigen Informationen bekommen mit denen man das dort nachstellen kann.

Antwort: ich habe ein solches Projekt, dass sich nicht in 64 Bit compilieren lässt, weil der Compiler "zu wenig Speicher" hat. Werde die neue Version damit prüfen - drücken wir die Daumen...

Ergänzung zu Delphi 12.2
Die Fehlermeldung "Delphi 12.2 [dcc64 Fataler Fehler] Zu wenig Arbeitsspeicher" wird weiterhin erzeugt, obwohl der 64 Bit Compiler aktiviert ist.
Der Programmcode hat rund 150.000 Code-Lines...

Frage: könnte es hier andere Probleme geben, die bei Umschalten von 32 Bit auftreten?

Du musst in den Projekteinstellungen unter Delphi Compiler msBuild aktivieren und dort die Tool Architektur auf 64Bit umstellen. Dann erst wird der 64Bit Binary Compiler verwendet.

RE: Die msBuild war aktiviert. Möglicherweise gibt es hier ein ganz anderes Problem?

[MatthiasFehr]

Zitat:

Zitat von win568 (Beitrag 1541442)

Gibt es eine neue Möglichkeit, die Zielplattform zu erzwingen ? Wenn ich für ein Projekt die Zielplattform 64 Bit festlege, das Projekt speichere und wieder öffne, dann ist die Plattform auf einmal auf 32 Bit ?

RE: die Funktion des 64 Bit Compilers ist neu. Benötigt sicher etwas Training für uns.
Optimal wäre eine neue Option wie {64 Bit Comp ON} hilfreich?

[Kas Ob.]

Zitat:

Zitat von MatthiasFehr (Beitrag 1541433)

Zitat:

Zitat von MatthiasFehr (Beitrag 1541336)

Zitat:

Zitat von Uwe Raabe (Beitrag 1541321)

Zitat:

Zitat von win568 (Beitrag 1541319)

Wir warten seit Jahren auf die 64 Bit Compilerarchitektur, da unsere Anwendung nicht mehr ohne Absturz der IDE erzeugt werden kann.

Dazu kann ich leider nicht viel sagen, da mir bislang noch kein solches Projekt untergekommen ist. Eure spezielle Anwendung und die damit entstehenden Probleme kenne ich naturgemäß halt auch nicht. Ich vermute allerdings stark, dass auch Embarcadero hier nur Abhilfe schaffen kann, wenn sie die nötigen Informationen bekommen mit denen man das dort nachstellen kann.

Antwort: ich habe ein solches Projekt, dass sich nicht in 64 Bit compilieren lässt, weil der Compiler "zu wenig Speicher" hat. Werde die neue Version damit prüfen - drücken wir die Daumen...

Ergänzung zu Delphi 12.2
Die Fehlermeldung "Delphi 12.2 [dcc64 Fataler Fehler] Zu wenig Arbeitsspeicher" wird weiterhin erzeugt, obwohl der 64 Bit Compiler aktiviert ist.
Der Programmcode hat rund 150.000 Code-Lines...

Frage: könnte es hier andere Probleme geben, die bei Umschalten von 32 Bit auftreten?

This compiler fatal error with out of memory error is miss leading, it almost never about memory, in almost all cases (and here i am out of the touch with newer versions,) is from stack overflow or close enough to overflow, in other words the stack did ran out for the compiler compiling thread, as the compiler use and utilize the stack in nest and recursive way,
What does that mean ?
It means the deeper you code utilize inheritance the more stack it will eat, the solution simplify your OOP design and separate/untangle this deep nested inheritance.

[Friday]

Zitat:

Zitat von jaenicke (Beitrag 1541310)

Das hat ja nicht direkt mit 4k zu tun, sondern ob man die passende Bildschirmgröße im Verhältnis zur Auflösung gewählt hat. Ich kann auch mit 4k problemlos auf 100% arbeiten, aber dann darf das natürlich kein 24" Gerät sein, sondern ca. 28" oder mehr....

Da hast du wohl deutlich bessere Augen als ich :wink: Ich hab die 4k auf einem (eigentlich 3) 31,5" Monitor und es ist mir dennoch viel zu klein um die GUI Elemente da vernünftig zu platzieren.
Aber nun gehört zumindest das der Vergangenheit an.

[win568]

Zitat:

Zitat von MatthiasFehr (Beitrag 1541447)

Zitat:

Zitat von win568 (Beitrag 1541442)

Gibt es eine neue Möglichkeit, die Zielplattform zu erzwingen ? Wenn ich für ein Projekt die Zielplattform 64 Bit festlege, das Projekt speichere und wieder öffne, dann ist die Plattform auf einmal auf 32 Bit ?

RE: die Funktion des 64 Bit Compilers ist neu. Benötigt sicher etwas Training für uns.
Optimal wäre eine neue Option wie {64 Bit Comp ON} hilfreich?

Ich meine hier nicht die Compilerarchitektur sondern nur die Zielplattform. Unsere Projekte haben immer die Zielplattformen Win32 und Win64 um Beide erzeugen zu können. Bei beiden Plattformen wurde die Compilerarchitektur auf 64Bit Binary gestellt. Setze ich die 64 Bit Zielplattform auf aktiv und schließe das Projekt, dann wird beim Öffnen die Plattform auf Win32 als aktive Plattform umgestellt.
Auch wenn ich bei aktiver Zielplattform Win64 in die Optionen einsteige und den Dialog verlasse wird auf Win32 umgestellt.

[Uwe Raabe]

Ich kann das hier an einem simplen VCL-Projekt nicht nachvollziehen. Die eingestellte Zielplattform wird beim Schließen (nach Bestätigung der Speichern-Frage) korrekt vermerkt und beim nächsten Öffnen wieder hergestellt.

Könnte es an einem Plugin liegen?

[win568]

Zitat:

Zitat von Uwe Raabe (Beitrag 1541455)

Ich kann das hier an einem simplen VCL-Projekt nicht nachvollziehen. Die eingestellte Zielplattform wird beim Schließen (nach Bestätigung der Speichern-Frage) korrekt vermerkt und beim nächsten Öffnen wieder hergestellt.

Könnte es an einem Plugin liegen?

Nein, das wird immer erst getestet. Tritt auch ohne Plugin auf

[Uwe Raabe]

Was steht denn nach dem Schließen in der dproj?

Code:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PropertyGroup>
        <ProjectGuid>{AC715E4E-812B-4CAF-8E96-BE42B7B7FE60}</ProjectGuid>
        <ProjectVersion>20.2</ProjectVersion>
        <FrameworkType>VCL</FrameworkType>
        <Base>True</Base>
        <Config Condition="'$(Config)'==''">Debug</Config>
        <Platform Condition="'$(Platform)'==''">Win64</Platform>
        <ProjectName Condition="'$(ProjectName)'==''">Project1109</ProjectName>
        <TargetedPlatforms>3</TargetedPlatforms>
        <AppType>Application</AppType>

[DevidEspenschied]

Falls Ihr noch etwas mehr Informationen zum 12.2 Release benötigt, findet ihr nachfolgend einige deutsche Blogs dazu:

RAD Studio 12.2 Athens ist verfügbar

RAD Studio 12.2: Alle neuen und verbesserten Funktionen

Verwendung von KI-LLMs in der RAD Studio IDE mit Smart CodeInsight

Zu TParallelArray folgt auch noch kurzfristig mehr Inhalt...

[win568]

Zitat:

Zitat von Uwe Raabe (Beitrag 1541461)

Was steht denn nach dem Schließen in der dproj?

Code:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PropertyGroup>
        <ProjectGuid>{AC715E4E-812B-4CAF-8E96-BE42B7B7FE60}</ProjectGuid>
        <ProjectVersion>20.2</ProjectVersion>
        <FrameworkType>VCL</FrameworkType>
        <Base>True</Base>
        <Config Condition="'$(Config)'==''">Debug</Config>
        <Platform Condition="'$(Platform)'==''">Win64</Platform>
        <ProjectName Condition="'$(ProjectName)'==''">Project1109</ProjectName>
        <TargetedPlatforms>3</TargetedPlatforms>
        <AppType>Application</AppType>

Hallo Uwe

Ich habe den Grund gefunden. In der Datei war zusätzlich zu der Platform Condition noch ein Tag Platform vorhanden. Nach Rauslöschen hat es funktioniert.

[himitsu]

ääääähhhhh, aber das gehört da rein.

Früher fehlte es mal, aber das war ein böser Fehler, weil man dann z.B. dem MSBuild nicht mehr via Parameter mitgeben kann, was gemacht werden soll.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1541516)

ääääähhhhh, aber das gehört da rein.

Früher fehlte es mal, aber das war ein böser Fehler, weil man dann z.B. dem MSBuild nicht mehr via Parameter mitgeben kann, was gemacht werden soll.

Kannst du das mal erläutern? Warum sollte es zwei separate Platform-Einträge da geben? Einer genügt ja wohl.

[himitsu]

Ohhh, falsch verstanden.
Nicht "ein" Platform, wovon er die Condition gelöscht hat :wall:

Nja, dennoch ist ein Platform ohne Condition falsch, weil das ja immer überschreibt.

[win568]

Geschalten wird aber nur <Platform Condition="'$(Platform)'==''">Win64</Platform>, wenn man die Platform aktiviert.

[ggscholz]

Gibt es hier oder bei Emba einen Hinweis/Tip, wie ein aktuelles 12.1 auf 12.2 gebracht werden kann? Und dann auch funktioniert.

Ich find dazu nichts! Lad mir aber auch grad erst die ISO runter, vielleicht gibts da ja Hinweise.

Grüße Gerd

[Uwe Raabe]

Ich habe hier mehrere Systeme erfolgreich von 12.1 auf 12.2 gebracht. Setup starten, keine Änderungen, einfach weiterklicken wenn man aufgefordert wird. Das heißt aber ja nicht, dass das überall so läuft.

[himitsu]

Da alle 12.x die gleiche CompilerVersion IDE-Version sind, geht es hier auf ein Upgrade hinaus. (nicht parallel installierbar, wie z.B. zu 11.x, 10.x, oder XE8, XE7 usw.)

Und da man es aufgegeben hat ein "Upgrade" für sein Setup hinzubekommen (der letzte Versuch war ja extrem grottig langsam),
muß, bzw. wird automatisch die alte 12.x deinstalliert, bevor der eigentliche Installations-Vorgang beginnt.

Die Registry (Einstellungen) kann man beibehalten (kann sie aber beim Deinstallieren auch zurücksetzen löschen lassen).
Natürlich kann man hier auch vorher die Einstellungen mit MigrationsTool speichern (warum bietet das Setup das eigetlich nicht von sich aus an?) und nachher (teilweise) wiederherstellen.
GetIt geht dabei verloren, weil das mit deinstalliert wird.
Also wenn man nicht die GetItCmd nutzt, muß man nachher alles Packages einzeln extrem umständlich wieder installieren (und sich vorher merken, was installiert was).
Auch mit "eigenen" Komponenteninstallationen muß man bei nicht gelöschter Registry aufpassen.

Ausnahme, wenn man die Registry nicht löschen/zurücksetzen lässt, da der Schrott nicht richtig deinstalliert wird, sind z.B. Parnassus oder JEDI, welche teilweise erhalten bleiben und in der neuen Delphi-Version erstmal liebendgern knallen.

[himitsu]

Dieses MigrationsTool ist ja immernoch ... boar ehhhh, mir fällt kein Wort für ein ...

Es hat gerade eben erfolgreich den 12.1-Patch1 in der 12.2 installiert und nun knallt alles weg. :thumb:
Außerdem wurden von allen anderen Packages die alten Versionen installiert, anstatt jene, welche im GetIt eigentlich zu Auswahl stünden.

https://embt.atlassian.net/servicede...tal/1/RSS-1965
https://embt.atlassian.net/servicede...tal/1/RSS-1966

[Rollo62]

Zitat:

Zitat von ggscholz (Beitrag 1541584)

Gibt es hier oder bei Emba einen Hinweis/Tip, wie ein aktuelles 12.1 auf 12.2 gebracht werden kann? Und dann auch funktioniert.

Wenn Du wirklich nicht einfach updaten kannst, dann habe ich für mich immer ein clean install vorgesehen.
D.h. alle verstreuten Fragmente, SDKs, JDKs, Registry Einträge, Verzeichnisse wirklich hart löschen,
damit der Installer das alles neu anlegen muss.
Manchmal kann z.B. ein XML Template-File in einer neuen Version erweitert werden, was wan dann so ohne weiteres gar nicht bemerkt, wenn dies schiefläuft.

Für mich hat das immer gut funktioniert und gibt mir auch die Sicherheit, dass ich es genau so installiert habe,
wie der Schöpfer es sich gedacht hat.

Am Besten geht das natürlich in einer VM, und immer nur eine IDE Version pro VM.

[himitsu]

Mit {$ZEROBASEDSTRINGS ON} kann der Debugger auch irgendwie nicht umgehn. :freak:

[himitsu]

Und das Backup ist natürlich immernoch kaputt.
https://embt.atlassian.net/servicede...tal/1/RSS-2017

Man muß also selbst dran denken, vorher das gespeicherte Backup zu nochmal zu sichern/kopieren
und es dann selbst wiederherzustellen. :freak:

Mir war grade einfach so beim Codeschreiben die IDE hängengeblieben und ist nach 'ner gefühlten Minute einfach so wortlos im Nirvana verschwunden.


Das Ereignislog sagt .... Wann schmeißen die endlich diesen .NET-Schrott raus?

Zitat:

Name der fehlerhaften Anwendung: bds.exe, Version: 29.0.53571.9782, Zeitstempel: 0x66d2e9f5
Name des fehlerhaften Moduls: clr.dll, Version: 4.8.9261.0, Zeitstempel: 0x667a1900
Ausnahmecode: 0xc00000fd
Fehleroffset: 0x0045942a
ID des fehlerhaften Prozesses: 0x0xA6EC
Startzeit der fehlerhaften Anwendung: 0x0x1DB15A36635EA05
Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\Embarcadero\Studio\23.0\bin\bds.exe
Pfad des fehlerhaften Moduls: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr. dll
Berichtskennung: 502a9a9d-9980-4af4-aa61-10febd187ef0
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

[Rollo62]

Zitat:

Zitat von himitsu (Beitrag 1541771)

Mit {$ZEROBASEDSTRINGS ON} kann der Debugger auch irgendwie nicht umgehn. :freak:

Was genau ist denn da anders als vorher, der DEFAULT Wert?

Laut Hilfe sollte es noch so sein:

Zitat:

- Delphi string type helpers (TStringHelper) remain 0-based.
- All Delphi global flat functions are 1-based.

Ich nutze für meinen Teil, wenn ich 0-based möchte ausschließlich die type helper, und
wenn ich das traditionell 1-based möchte die normalen Delphi Indizes ( mit oder ohne High()/Low() ).

Das ist schon schlimm genug und dann noch eine zusäzliche Schwierigkeit mit $ZEROBASEDSTRINGS einzubauen kann ich sowieso keinem emppfehlen.
Für welchen realen Anwendungsfall genau sollte man das machen (Ok, vielleicht außer Zwang durch externe 3rd Party Libraries )?

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1541782)

Mir war grade einfach so beim Codeschreiben die IDE hängengeblieben und ist nach 'ner gefühlten Minute einfach so wortlos im Nirvana verschwunden.

Das ist mir vor kurzem auch ein paar mal hintereinander passiert, aber ich konnte es dann nicht mehr reproduzieren. Gefühlt passiert es wenn ich in der DPR/DPK arbeite.

[HRolle]

Zitat:

Zitat von himitsu (Beitrag 1541782)

Das Ereignislog sagt .... Wann schmeißen die endlich diesen .NET-Schrott raus?

Zitat:

Name der fehlerhaften Anwendung: bds.exe, Version: 29.0.53571.9782, Zeitstempel: 0x66d2e9f5
Name des fehlerhaften Moduls: clr.dll, Version: 4.8.9261.0, Zeitstempel: 0x667a1900
Ausnahmecode: 0xc00000fd
Fehleroffset: 0x0045942a
ID des fehlerhaften Prozesses: 0x0xA6EC
Startzeit der fehlerhaften Anwendung: 0x0x1DB15A36635EA05
Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\Embarcadero\Studio\23.0\bin\bds.exe
Pfad des fehlerhaften Moduls: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr. dll
Berichtskennung: 502a9a9d-9980-4af4-aa61-10febd187ef0
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

Das .Net-Framework 4.0 ist seit 12.1.2016 "Out of Support", kann dadurch Fehler beim Zugriff auf Betriebssystemkomponenten ab Windows 10 haben. Es wäre wirklich dringlichst nötig BDS und vielleicht noch andere Komponenten, die auf ältere .Net-Framework-Varianten zugreifen, zu überarbeiten.

[himitsu]

Zitat:

Zitat von Rollo62 (Beitrag 1541787)

Was genau ist denn da anders als vorher, der DEFAULT Wert?

OFF

Gut, es betrifft nur den Zugriff auf den String selbst (Funktionen ala Copy und Pos sind leider nicht inbegriffen),
und der Code an sich funktioniert ja (scheinbar), aber der Debugger zeigt halt Mist an, z.B. bei mystring[idx] den falschen Char.

OK, ich Nutze es hier im Windows, in einem Teil des Codes,
aber es war ja mal eine ganze Weile als Zwang drin, paar Jährchen, für die damals "neuen" Mobilen Platformen ... da könnte man doch erwarten, dass es jemand auch mal getestet hatte. :freak:

[himitsu]

Oftmals doppelter oder unsichtbarer Cursor.

Nachdem ich grade selbst versucht hab in ein TMemo zu malen, verstehe ich, warum das bei denen ständig im Code-Editor passiert.

Nur hab ich es hinbekommen, dass es bei mir nicht mehr passiert und ich weiß auch, warum es so ist. :stupid:
http://fnse.de/TMemoCustomDraw.mp4 (sieht in dem SnippingTool-Video nur schlimmer aus, als es ist :?)