Moin,

ich würde die verschiedenen Themengebiete rund um XE8 gern ein wenig bündeln und kanalisieren, damit derjenige, der Informationen sucht (sei es zu Fehlern, Feature oder sonstwas) dazu auch eine Chance hat.
Gern vermeiden würde ich einen Sammelthread von 428 Seiten, der am Ende so ziemlich alles enthält.

//Edit:
Ziel dieses Threads soll es sein, Fehler zu diskutieren, aber auch zielgerichtet zu reproduzieren und dann mit Beispiel im Quality-Portal einzutragen. Nur ein Allgemeines "Ach ist das alles wieder Schlimm" mit einem zeitgleichen Zusammenklatschen der Hände über dem Kopf ist hier nicht hilfreich.

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 tueddy:

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.

Nachdem nach den Installation Notes 10.9 die minimale OS-Version ist wirds da auch nichts mehr geben. Es wäre zwar schön alte OSX-Versionen zu unterstützen, aber das wird vergebene Liebesmühe sein XEx immer mit 10,6 kompatible zu halten.

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.

Der PAServer16 ließ sich erst auf dem MAC installieren, nachdem ich die Sprache auf English umgestellt hatte (also nur im Setup-Dialog selber). Bei Deutsch passierte nichts, wenn man die Lizenzbedingungen akzeptiert hatte.

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.