Moin,

eine Delphi XE-8 Anwendung crasht auf MacOS 10.6. Das ist zwar ein relativ altes System, viele Mac-User benutzen es aber noch. Der Fehler wurde in der Beta-Phase gemeldet aber nicht gefixt. Grund ist der Zugriff auf die Eigenschaft "backingScaleFactor", die erst mit 10.7 eingeführt wurde. Hier der Workaround:

markieren

Code:

Patch #1:

function TPlatformCocoa.GetDisplayMetrics: TDeviceDisplayMetrics;
const
MacBasePPI = 110;
var
Screen: NSScreen;
ScreenSize: TPointF;
ScreenScale: Single;
begin
Screen := TNSScreen.Wrap(TNSScreen.OCClass.mainScreen);
ScreenSize := TPointF(Screen.frame.size);
// +++ add this OS check +++
if NSAppKitVersionNumber >= NSAppKitVersionNumber10_7 then
ScreenScale := Screen.backingScaleFactor
else
ScreenScale := 1.0;
...

Patch #2:

function TPlatformCocoa.GetScreenScale: Single;
begin
// +++ add this OS check +++
if NSAppKitVersionNumber >= NSAppKitVersionNumber10_7 then
Result := TNSScreen.Wrap(TNSScreen.OCClass.mainScreen).backingScaleFactor
else
Result := 1.0;
end;

Patch #3:
procedure AddDevices;

var

  Screen: NSScreen;

  Rect: NSRect;

  LogicalSize, PhysicalSize: TSize;

  Scale: CGFloat;

  DeviceID: string;

begin

  Screen := TNSScreen.Wrap(TNSScreen.OCClass.mainScreen);

  Rect := Screen.frame;

  // +++ check for MacOS 10.7 here +++

  if NSAppKitVersionNumber >= NSAppKitVersionNumber10_7 then

    Scale := Screen.backingScaleFactor

  else

    Scale := 1.0;

...

Was auch nicht geht ist folgendes:

Ich erstelle oder übernehme ein altes Projekt. Dann kompiliere ich es für Android oder iOS und starte das dann auf dem Gerät. Wenn ich nun das Debuggen beende, die Zielplattform auf Win32 stelle und Strg+F9 drücke stürzt die IDE fast immer ab. Danach kommt ein Runtime Error und ein Verweis auf einen offensichtlichen Nullpointer zugriff.

Was auch nervig ist, ist folgendes. Ich habe die Angewohnheit beim Debuggen unter Windows gerne nachdem ich einen Breakpoint erreicht habe und meine "Erkenntnis" aus den Werten erhalten habe, mit Strg+F2 den Debugvorgang zu beenden. Es passiert nach 2-3 Debugs regelmäßig, dass ich danach nicht mehr die Anwendung kompilieren kann. Angeblich kann die Exe nicht erstellt werden und ein wechseln von Debug auf Release geht auch nicht. Lediglich ein Neustart der IDE hilft dabei.

Mal abgesehen dass es nahezu unmöglich ist ein größeres Projekt für Android oder iOS mal komplett neu zu kompilieren, ohne einen kein freier Arbeitspeicher mehr vorhanden zu erhalten. Jetzt nicht falsch verstehen, ich kann ohne Brille noch Abends die IDE ablesen und das Castalia ist recht nett, aber die ganzen Probleme sind unter aller Kanone.

Mal eine blöde Frage: Hat jemand (außer mir) mal ein größeres Projekt kompiliert? Wir nutzen hier nicht exzessiv irgendwelche Thirdparty Bibliotheken, aber das ERP Projekt hier hat knapp 4mb reinen Quellcode über die Jahre zusammengesammelt, die Formulare und den dazugehörigen Eingabe/Ausgabecode rechne ich jetzt nicht mit ein.

Zitat von Peter666:

Ich erstelle oder übernehme ein altes Projekt. Dann kompiliere ich es für Android oder iOS und starte das dann auf dem Gerät. Wenn ich nun das Debuggen beende, die Zielplattform auf Win32 stelle und Strg+F9 drücke stürzt die IDE fast immer ab. Danach kommt ein Runtime Error und ein Verweis auf einen offensichtlichen Nullpointer zugriff.

Und wenn Du die Zielplattform nicht änderst? Geht es dann?

Zitat von Peter666:

Mal eine blöde Frage: Hat jemand (außer mir) mal ein größeres Projekt kompiliert?

- Ja...
- Auch ein Video vom Speicherverbrauch gemacht...
- Diese auch direkt per eMail an einen der Entwickler gesendet...
- Und noch über eine andere Quelle zu EMBT gemeldet...

Leider ist es noch schlimmer als unter XE7...

Zitat von Peter666:

Mal abgesehen dass es nahezu unmöglich ist ein größeres Projekt für Android oder iOS mal komplett neu zu kompilieren, ohne einen kein freier Arbeitspeicher mehr vorhanden zu erhalten. Jetzt nicht falsch verstehen, ich kann ohne Brille noch Abends die IDE ablesen und das Castalia ist recht nett, aber die ganzen Probleme sind unter aller Kanone.

Nur um mal ein Gefühl für die Größen zu erhalten: Wie groß ist denn bei Dir "etwas größer"?
Das Problem ist EMBT bekannt, 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. Ich weiß, dass dieser Schuh sowohl Dich und auch andere Anwender drückt, aber auch EMBT.

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.

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.