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

Zitat von Daniel:

Nur um mal ein Gefühl für die Größen zu erhalten: Wie groß ist denn bei Dir "etwas größer"?

Also bei uns gab es das Problem mit dem Speicher bei XE7 schon bei Projekten mit unter 200k LOC (plus bereits kompiliert vorliegende weitere Units usw., u.a. aus Bibliotheken wie den JEDIs) was ich nicht als sonderlich groß ansehen würde.
Dabei reichte es bei XE7 das Projekt zwei oder drei Mal zu kompilieren damit die IDE mit OutOfMemory abstürzte.
// EDIT: Und bei Projektgruppen war schon beim ersten Mal kompilieren beim dritten oder vierten Projekt Schluss wobei dort die Projekte sogar noch kleiner waren.

XE8 konnte ich mangels der JEDIs noch nicht testen, diesmal habe ich keine Zeit die Anpassung zuerst Quick&Dirty selbst zu machen. Aber ich werde es dann auch mit XE8 testen.