Zitat von Daniel:

die nächstbeste Lösung wird drin bestehen, die IDE "large address aware" zu kompilieren und ihr damit und ein GB mehr an Speicher zu Verfügung zu stellen.

Wie wäre es mit er 64 bit Version und Ende mit dem Speicherproblem...

Es wird kaum jemand mehr als 16 Exbibyte Speicher fürs compilieren brauchen...
Aber wer hat schon ein Mainboard wo soviel drauf passt...

Laut Marco haben sie auch das auf dem Radar, da aber sämtlicher Komponenten in der IDE leben, müssten auch diese den Sprung mitmachen. Für VCL und FMX kein Problem, aber für viele andere, kleinere Komponenten würde dies vorerst das Aus bedeuten. Andernfalls müsste man die Architektur der IDE ändern, dass eine Art Mischbetrieb möglich würde.
Aber all das ist eben ein ferneres Ziel als das o.g. eine zusätzliche GByte.

Zitat von Daniel:

aber für viele andere, kleinere Komponenten würde dies vorerst das Aus bedeuten.

Echt? Die Komponenten die Unicodestrings überstanden haben und die auch schon in 64-Bit Anwendungen laufen?
Wenn dürfte das nur Komponenten ala GExpert und Co. betreffen.

Zitat von Daniel:

Andernfalls müsste man die Architektur der IDE ändern, dass eine Art Mischbetrieb möglich würde.

Blos nicht. Eine hier auf Mixed 32/64-Bit Betrieb aufgebaute Architektur wäre rausgeschmissenes Geld. Heutzutage kann man für die IDE 64 Bit vorraussetzen. Nur der Remote Debugger wird noch einige Zeit als 32-Bit Anwendung benötigt.

Allein die IDE besteht aus über 70 größeren Fremdkomponenten.
Selbst die Prüfung+Anpassung für Large-Aware dauert da eine Weile.
Bei 64-Bit muß praktisch alles geprüft und geändert werden.

Alle externen Fremdkomponenten müssen ihre Design-Time-Packages und Experten ebenfalls für 64 Bit anbieten.
> selbst GExperts, CnPack, ModelMaker, Castalia, die JEDI-Experten usw. hatten bisher noch keinen Grund ihren IDE-Code für 64 Bit auszulegen.

In einem 32 Bit-Windows wird diese IDE dann natürlich nicht mehr laufen.
Und ich glaub auch kaum, daß Embarcadero zwei IDEs parallel entwickeln will/wird.


Vielleicht wäre es besser, wenn man Vieles als Out-of-Process-Server auslagert.
Nebenbei würde auch eventuell nicht mehr gleich die ganze IDE abkratzen, wenn so ein Teil verreckt.

Firemonkey:

TScrollbox auflegen, TPanel einfügen. Scrollbar ist unten rechts da,
schiebt man das Panel aber nach oben links bleiben die Scrollbars unsichtbar, siehe angehängtes Bild.
Auch dieser Bug wurde vor längerer Zeit berichtet, ohne Worte..

Zitat von tueddy:

Firemonkey:

TScrollbox auflegen, TPanel einfügen. Scrollbar ist unten rechts da,
schiebt man das Panel aber nach oben links bleiben die Scrollbars unsichtbar, siehe angehängtes Bild.
Auch dieser Bug wurde vor längerer Zeit berichtet, ohne Worte..

Kann ich bestätigen. Habe gerade mal nach einer entsprechenden Meldung bei QC gesucht, weil ich mit einem Vote die Behebung des Fehlers unterstützen wollte. Habe da aber nichts gefunden. Kannst Du mir den Link zu dem Eintrag mal nennen, damit ich voten kann?

Zitat von tueddy:

Firemonkey:
TScrollbox auflegen, TPanel einfügen. Scrollbar ist unten rechts da,
schiebt man das Panel aber nach oben links bleiben die Scrollbars unsichtbar, siehe angehängtes Bild.

Das kann ich hier nachstellen. Alles, was nach rechts bzw. unten rausragt, erzeugt korrekte Scrollbalken.
Wenn ein Element NUR nach links bzw. oben rausragt, sehen wir keine Scrollbalken, dafür wird das Element zur Laufzeit in den sichtbaren Bereich verschoben.
Sicherlich könnte man das ändern, ich wüsste aktuell nur keinen Anwendungsfall, in dem es einen Sinn ergeben würde, ein Control halb links rauszuschieben OHNE dafür weiter rechts irgendwas anderes anzuzeigen. Denn das von Dir beschriebe Szenario tritt nur dann ein, wenn das Panel, das halb links raushängt, das einzige Control in der Scrollbox ist.
Screen Shot 2015-04-08 at 08.27.17.png

Beispiele...

Compiliert für Android:

Failure [INSTALL_PARSE_FAILED_MANIFEST_MALFORMED]...

Abgesehen davon, dass absolute Pfade zu einer classes.dex drin sind die es nicht gibt.

Zitat von Daniel:

Sicherlich könnte man das ändern, ich wüsste aktuell nur keinen Anwendungsfall, in dem es einen Sinn ergeben würde, ein Control halb links rauszuschieben OHNE dafür weiter rechts irgendwas anderes anzuzeigen. Denn das von Dir beschriebe Szenario tritt nur dann ein, wenn das Panel, das halb links raushängt, das einzige Control in der Scrollbox ist.

Stimmt, bei genauerer Betrachtung ist das kein Fehler. Davon abgesehen, verhält sich die VCL-Scrollbox auch nicht anders.

Zitat von Mavarik:

Wie wäre es mit er 64 bit Version und Ende mit dem Speicherproblem...

Genau das wurde uns mal vorgeschlagen als wir wegen Speicherprobleme bei einer (Nicht-Delphi) Komponente probleme hatten.
Glücklicherweise war unser Kunde für den wir diese Komponente eingebaut hatten groß genug den Komponentenlieferanten (über die finanzielle Schiene) klar zu machen das 64-Bit hier keine Lösung ist.