Der XE8 Fehler-Thread

[Daniel]

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.

[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. Hier der Workaround:

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;

...

[Peter666]

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.

[Daniel]

Zitat:

Zitat von Peter666 (Beitrag 1296553)

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?

[Mavarik]

Zitat:

Zitat von Peter666 (Beitrag 1296553)

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

[Bernhard Geyer]

Zitat:

Zitat von tueddy (Beitrag 1296551)

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.

[Daniel]

Zitat:

Zitat von Peter666 (Beitrag 1296553)

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.

[Harry Stahl]

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.

[Mavarik]

Zitat:

Zitat von Daniel (Beitrag 1296558)

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

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

[Daniel]

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.

[Bernhard Geyer]

Zitat:

Zitat von Mavarik (Beitrag 1296561)

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

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.

[Bernhard Geyer]

Zitat:

Zitat von Daniel (Beitrag 1296564)

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:

Zitat von Daniel (Beitrag 1296564)

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.

[himitsu]

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.

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

[Harry Stahl]

Zitat:

Zitat von tueddy (Beitrag 1296574)

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?

[jaenicke]

Zitat:

Zitat von Daniel (Beitrag 1296558)

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.

[Daniel]

Zitat:

Zitat von Harry Stahl (Beitrag 1296560)

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.

:gruebel: Ich habe gerade mal versucht, dies nachzustellen.
Ich kann den PAServer auf mit allen Sprach-Einstellungen installieren.
Mein MacOS war erst auf Englisch, danach - nach einem Neustart - dann auf Deutsch eingestellt.

[Daniel]

Zitat:

Zitat von tueddy (Beitrag 1296574)

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

[Mavarik]

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.

[Daniel]

... und das Beispiel ist wo?
Ich glaube Dir selbstverständlich, dass Du diesen Fehler auf Deinem System hast. Doch mit diesem Informationsgehalt lässt sich da für uns nichts daraus machen. Weder eine Lösung noch ein Bugreport.

[Mavarik]

Zitat:

Zitat von Daniel (Beitrag 1296689)

... und das Beispiel ist wo?
Ich glaube Dir selbstverständlich, dass Du diesen Fehler auf Deinem System hast. Doch mit diesem Informationsgehalt lässt sich da für uns nichts daraus machen. Weder eine Lösung noch ein Bugreport.

OMG... 3 Beispiele getestet keins Funktioniert. (Aktuelles Repo)

Beim 4. [DCC Fataler Fehler] ... F2046 Zu wenig Arbeitsspeicher...
Daher wiederhole ich nochmal meine Survey: [X] not ready to ship...
Bildschirm schwarz...Speicherverbrauch der IDE 1.173.896K (Um 4 Beispiele zu compilieren)
Save-Dialog ist aus "glass" daher kann ich meine offenen Projekte auch nicht mehr Speichern...

Samples\Object Pascal\Mobile Samples\Device Sensors and Services\Maps
Samples\Object Pascal\Mobile Samples\Device Sensors and Services\Map Type Selector
Samples\Object Pascal\Mobile Samples\Physics\TestBed

Wenn Du versuchst TestBed für Android zu übersetzen bekommst Du die Fehlermeldung, dass die Declaration nicht mit der Parameterliste der Procedure übereinstimmt...

[Daniel]

Okay, Du hast also nacheinander die o.g. vier mitgelieferten Beispiele kompiliert?
Das ist schon eine notwendige Information. ;-)

Ich gucke mir das nach dem Mittagessen mal an.

[Union]

Ich bekomme XE8 nicht einmal installiert. Nach der Setup-Sprachauswahl erscheint der Installationsdialog und direkt danach "BDS funktioniert nicht mehr". In der Problemsignatur erscheint als Auslöser "ETTracker.dll_unloaded". Im Temp-Verzeichnis befinden sich "mia" Verzeichnisse, die diese dll enthalten. Auch nach dem Löschen des Temp schlägt die Installation fehl. Kennt jemand dieses Problem?

[Daniel]

Benutzt Du Windows XP? Im Zusammenhang mit der ETTracker.dll gab es da Probleme.
Andere Benutzer sagten, sie hätten sie einfach gelöscht, während das Setup läuft - das soll geholfen haben.

[Bernhard Geyer]

Zitat:

Zitat von Union (Beitrag 1296710)

Ich bekomme XE8 nicht einmal installiert. Nach der Setup-Sprachauswahl erscheint der Installationsdialog und direkt danach "BDS funktioniert nicht mehr". In der Problemsignatur erscheint als Auslöser "ETTracker.dll_unloaded". Im Temp-Verzeichnis befinden sich "mia" Verzeichnisse, die diese dll enthalten. Auch nach dem Löschen des Temp schlägt die Installation fehl. Kennt jemand dieses Problem?

Hatte ich gestern 1*. Beim zweiten Starten hat es geklappt - Hab es auf Remote Desktop geschoben...

Zitat:

Zitat von Daniel (Beitrag 1296713)

Benutzt Du Windows XP?

XP und XE8 - Da XP nicht mehr supportet ist wäre ein funktionsfähige Installation Zufall.

[Union]

Zitat:

Zitat von Daniel (Beitrag 1296713)

Benutzt Du Windows XP? Im Zusammenhang mit der ETTracker.dll gab es da Probleme.
Andere Benutzer sagten, sie hätten sie einfach gelöscht, während das Setup läuft - das soll geholfen haben.

Das ist Windows 8.1 und das Setup läuft ja eben gar nicht. In Delphi-Kategorien gedacht scheint es beim FormActivate oder FormShow aufzutreten.

[EDIT]
Sie müssen für die Installation des Produkts Microsoft Windows 7 oder Windows 8 als Administrator ausführen oder auf der Administratorberechtigungsliste stehen.
[/EDIT]
Willkommen im 21. Jahrhundert. Geht also nur in der VM, da wir hier niemals Admin-Rechte bekommen.

[tueddy]

Nächster Fehler, ebenfalls mehrfach berichtet (RSB-640, QC 107919, RSP-9807):

"Windows VCL & FMX applications fails to get Windows Logo certified"

Delphi Anwendungen bestehen die Windows Logo Test nicht, siehe Bild.

[Bernhard Geyer]

Zitat:

Zitat von Union (Beitrag 1296720)

[EDIT]
Sie müssen für die Installation des Produkts Microsoft Windows 7 oder Windows 8 als Administrator ausführen oder auf der Administratorberechtigungsliste stehen.
[/EDIT]

Könnte man überhaupt eine IDE mit Debugger und diversen Einhängmöglichkeiten in IIS und Co. überhaupt ohne Adminrechte hin bekommen?

Zitat:

Zitat von Union (Beitrag 1296720)

Willkommen im 21. Jahrhundert. Geht also nur in der VM, da wir hier niemals Admin-Rechte bekommen.

Wenn Ihr keine (lokalen) Adminrechte bekommt dann ist es wohl die Aufgabe der IT solche SW zu installieren. Es ist immerhin nötiges Arbeitsmittel.
Fehler ist natürlich das der Installer hier das nicht selbständig erkennt und abfängt? Oder Versucht er es, aber schafft es nicht zuverlässig.

[greenmile]

Man wartet doch immer bis zum ersten Servicepack / Update ... Das dauert meist nicht lange. Bis dahin kann man sich die Arbeit echt sparen, spätestens dann muss man wieder alles neu installieren.

[tueddy]

[MacOS] FMX ScreenReader can crash the application! (berichtet am 11.02.2015)

In FMX.ScreenReader.MAC.pas the is a global variable "FocusedCtrl".
If a second form is shown & freed, the variable FocusedCtrl can point to a control which has already been freed.

In various places the variable is accessed and can be a dangling pointer -> BUUUM

Workaround in FMX.ScreenReader.MAC.pas:

Code:

destructor TAccForm.Destroy;
var
  MyControl: TFmxObject;
begin
  FEditTimer.Free;
  FEditMouseUp.Free;

  // Make sure freed form has no longer reference to control
  MyControl:= FocusedCtrl;
  while Assigned(MyControl) do
    begin
      if (MyControl is TForm) and ((MyControl as TForm) = Self) then
        begin
          FocusedCtrl:= nil;
          Break;
        end;
      MyControl:= MyControl.Parent;
    end;
  inherited;
end;

[himitsu]

Zu der einen gewissen "Antwort" sag ich jetzt mal nix.
PS: Ich werde absichtlich kleingeschrieben.



Und ansonsten

Zitat:

Keine Adminrechte

Zum Installieren benötigt man nunmal gewisse Rechte, um in die verschiedenen Verzeichnisse und Registrypfade schreiben zu dürfen, sowie Debugger und Co. registrieren zu können.

Man wird Delphi doch bestimmt auch irgendwie über die Domain (Firmen-Server) installieren können?
Einfach mal beim Emba-Support nachfragen.

Oder mal in Richtung All-Access (AppWave) schauen. Ich weiß aber nicht, in wie weit dessen Installer Adminrechte benötigt.

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1296734)

Zu der einen gewissen "Antwort" sag ich jetzt mal nix.

ich würde sagen: Puderchen rausschmeißen und Account sperren.
Allein schon die nazi-mod-Aussage ist schon mehr als eine Frechheit.
Bei solchen Beleidigungen wäre es auch eine Überlegung diesen "User" strafrechtlich zu verklagen..

[Mavarik]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1296736)

Zitat:

Zitat von himitsu (Beitrag 1296734)

Zu der einen gewissen "Antwort" sag ich jetzt mal nix.

ich würde sagen: Puderchen rausschmeißen und Account sperren.
Allein schon die nazi-mod-Aussage ist schon mehr als eine Frechheit.
Bei solchen Beleidigungen wäre es auch eine Überlegung diesen "User" strafrechtlich zu verklagen..

Und ich schreibe mich nicht mit e, euch ganz bewusst...

"strafrechtlich" jo mal die logs & IP speichern...

[Guido R.]

Mal zurück zu den XE8-Fehlern...

Ich habe gerade mal das AppTethering-Sample "Photo-Wall" ausprobiert und anscheinend schmieren Android-(AppTethering)-Apps beim Beenden immer noch mit einem Segmentation fault (11) in der Prozedur "TIdSocketHandle.Disconnect" ab.
Traurig, wenn schon die eigenen Samples nicht wirklich funktionieren. Bin mal gespannt, ob sich etwas im REST-Bereich getan hat, insbes. in der OAuth1Authentication, die bislang ohne massive Eingriffe praktisch unbenutzbar war.

Guido R.

[Harry Stahl]

Zitat:

Zitat von Daniel (Beitrag 1296593)

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.

[arnof]

Zitat:

Zitat von tueddy (Beitrag 1296727)

Nächster Fehler, ebenfalls mehrfach berichtet (RSB-640, QC 107919, RSP-9807):

"Windows VCL & FMX applications fails to get Windows Logo certified"

Delphi Anwendungen bestehen die Windows Logo Test nicht, siehe Bild.

PrinterIndex:=-1

Das ist auch eine nicht übliche Sache, lass das mal weg und gebe hier einen Sinnvollen Wert an. Wenn Du hiermit nun deinem Programm sagen willst, das noch kein Drucker gewählt wurde, mach das einfach durch eine Variable....

Genau das wird im Log ja angemeckert das mit dem Devicememory nicht stimmt (ist null), das könnte am -1 liegen ....

[arnof]

Zitat:

Zitat von greenmile (Beitrag 1296730)

Man wartet doch immer bis zum ersten Servicepack / Update ... Das dauert meist nicht lange. Bis dahin kann man sich die Arbeit echt sparen, spätestens dann muss man wieder alles neu installieren.

Also ich kann sagen, die letzten Betas waren schon um einiges besser als XE7; das kann man hier ja teilweise Nachlesen: XE7 ist für Mobile Entwicklung fast nicht mehr zu gebrauchen.

[tueddy]

Zitat:

Zitat von arnof (Beitrag 1296803)

Zitat:

Zitat von tueddy (Beitrag 1296727)

Nächster Fehler, ebenfalls mehrfach berichtet (RSB-640, QC 107919, RSP-9807):

"Windows VCL & FMX applications fails to get Windows Logo certified"

Delphi Anwendungen bestehen die Windows Logo Test nicht, siehe Bild.

PrinterIndex:=-1

Das ist auch eine nicht übliche Sache, lass das mal weg und gebe hier einen Sinnvollen Wert an. Wenn Du hiermit nun deinem Programm sagen willst, das noch kein Drucker gewählt wurde, mach das einfach durch eine Variable....

Genau das wird im Log ja angemeckert das mit dem Devicememory nicht stimmt (ist null), das könnte am -1 liegen ....

Häh? PrinterIndex:= -1 bedeutet die Auswahl des Standarddruckers. Tut hier auch überhaupt nichts zur Sache.
JEDER Zugriff auf den Drucker besteht den Logotest nicht. Wenn's Dir nicht gefällt nimm doch

Code:

ComboBoxMyPrinters.Items.Assign(Printer.Printers);

Bitte doch selbst einmal testen, Application Verifier sollte jeder Windows-Entwickler installiert haben..

[arnof]

Dein Screenshot zeigt doch direkt das Problem an, das devmode: das ist der Treiberspeicher , der hier nicht da ist. Und hier solche Konstruktionen mit dem Druckertreiber auf undefiniert zu setzen, hier könnte man ja mal einen Zusammenhang herleiten ......8-)

[Sir Rufo]

Zitat:

Zitat von arnof (Beitrag 1296810)

Dein Screenshot zeigt doch direkt das Problem an, das devmode: das ist der Treiberspeicher , der hier nicht da ist. Und hier solche Konstruktionen mit dem Druckertreiber auf undefiniert zu setzen, hier könnte man ja mal einen Zusammenhang herleiten ......8-)

Wo wird denn da was auf undefiniert gesetzt? Hab ich jetzt schon das rote Gemüse auf den Augen?

Kleiner Hinweis http://docwiki.embarcadero.com/Libra...r.PrinterIndex

Somit kommt sollte der Fehler wohl eher in dem Wrapper zu finden sein als in der sagenhaften Zeile

Delphi-Quellcode:

Printer.PrinterIndex := -1;