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

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

Zitat von arnof:

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

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

markieren

Code:

ComboBoxMyPrinters.Items.Assign(Printer.Printers);

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

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

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

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 Printer.PrinterIndex := -1;

Sollte nur ein Tipp gewesen sein, wir kommen wieder mal vom Thema ab!

Nun habe ich auch Bugs beizutragen:

TAndroidNativeLightSensor geht nicht mehr (zeigt nur noch 0 an)

TAndroidNativePressureSensor geht nicht mehr (zeigt nur noch 0 an)

Leicht nach vollziehbar Sensordemo starten mit XE7 gehts und mit XE8 gehts nicht mehr

Zitat von arnof:

Sollte nur ein Tipp gewesen sein, wir kommen wieder mal vom Thema ab!

Aber wenn dein Tipp richtig ist, dann hat die Dokumentation doch einen Fehler und hier geht es doch um Fehler - ist ja der Fehler-Thread ...

Ja ja: bla bla bla ....

ok zum Thema:

mal schnell Debuggt wo der Käfer hängt:

FNativeSensor.DoStart; // das fehlt hier Arno

Das fehlt bei 3 Sensoren:

Magnetic, Pressure und Light

zusammenfalten · markieren

Delphi-Quellcode:

{ TAndroidNativeLightSensor }

constructor TAndroidNativeLightSensor.Create(AManager: TSensorManager);
begin
  inherited;
  FNativeSensor := TNativeSensor.Create(ASENSOR_TYPE_LIGHT);
  FNativeSensor.DoStart; // das fehlt hier Arno
end;

constructor TAndroidNativePressureSensor.Create(AManager: TSensorManager);
begin
  inherited;
  FNativeSensor := TNativeSensor.Create(ASENSOR_TYPE_PRESSURE);
  FNativeSensor.DoStart; // das fehlt hier Arno
end;

constructor TAndroidNativeMagneticSensor.Create(AManager: TSensorManager);
begin
  inherited;
  FNativeSensor := TNativeSensor.Create(ASENSOR_TYPE_MAGNETIC_FIELD);
  FNativeSensor.DoStart; // das fehlt hier Arno
end;

Zitat von Sir Rufo:

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

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 Printer.PrinterIndex := -1;

Der Fehler wird doch hier genau beschrieben + Fix:
http://qc.embarcadero.com/wc/qcmain.aspx?d=107919

Was mich nervt das Fehler berichtet werden inklusive FIX und sich bei Emb niemand darum kümmert. Hier wurde der Fehler berichtet am 14.08.2012.

Gerade habe ich diese Rückmeldung von JIRA zu einem anderen berichteten Fehler bekommen:

markieren

Code:

Re: [MacOS] System.ReportMemoryLeaksOnShutdown without function
As you reported, the documentation did not explain that this API member only worked on Windows. We have updated the documentation accordingly.

Das ist ja mal eine Super-Lösung: Anstelle der Fehlerbeseitigung wird einfach die Dokumentation entsprechend angepasst..

An der Stelle ließ es sich nicht schnell anders lösen.
In Windows wird FastMM verwendet, von welchem diese Funktion stammt.

Da müsste man dann auf die Idee kommen und noch ein Memory-Log dazwischenschalten, wobei der dann die Programme einen Hauch langsamer macht.
Oder man hätte die System-Speicheraufrufe vom FastMM entsprechend anpassen müssen, was ganz bestimmt auch möglich gewesen wäre.
Allerdings gibt es auch noch andere Third-Party-Memory-Debug-Komponenten.

Zitat von himitsu:

An der Stelle ließ es sich nicht schnell anders lösen.
In Windows wird FastMM verwendet, von welchem diese Funktion stammt.

?? FastMM4 in der aktuellen SVN Version kann Speicherleaks auch auf MacOS erkennen und anzeigen. Das funktioniert hervorragend.
Daher ist man jetzt nicht zwingend auf System.ReportMemoryLeaksAtShutdown angewiesen, wäre aber gut wenn das von Delphi transparent wie auf Windows funktionieren würde.

Viel schlimmer sind doch die gewaltigen (globalen) Leaks einer leeren MacOS FMX-Anwendung. Vielleicht scheut man sich bei Emb. genau deswegen davor:
Sehe ich keine Lecks sind sie auch nicht da..

Probiert das doch mal aus:

- Leere FMX Anwendung für MacOS
- FastMM4 aus SVN
- FullDebugMode einschalten
- libFastMM_FullDebugMode.dylib ins Deployment
- Detailierte .map Datei ins Deployment
- Anwendung starten und beenden

-> 20MB Logdatei mit Speicherlecks im AppBundle Ordner

Dieser Fehler wurde mehrfach berichtet, getan hat sich nichts:

RSP-9723 [MacOS] application gets terminated/Halt(0) on close. Incorrect unspooling
RSP-9726 Memory leaks in MacApi.ObjectiveC bridge
RSB-562 class destructor TVTableCache.Destroy is missing -> Memory leaks