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;

Moin.

A/V beim Laden der Demo-App "MobileControls.dpr" (siehe Anhang).

LG,
Marc

Hi,

Die Demo-App "\Object Pascal\Mobile Samples\Media\MusicPlayer" wurde wohl auch nicht fertiggestellt. Zumindest fehlt die Implementierung von TMusicPlayer (Interface ist auskommentiert).

LG,
Marc

Das ist nicht schön - nur als Hinweis am Rande: Der Demo-Ordner von XE8 ist die lokale Kopie eines SVN-Repositories.
Solltest Du also einen SVN-Client wie z.B. Tortoise installiert haben, kannst Du das Verzeichnis aktualisieren.
Ich habe das eben getan: 64 neue Dateien, 6 wurden entfernt und 14 aktualisiert.

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

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

In diesem Fall war ja auch die Dokumentation fehlerhaft, die offenbar suggerierte, daß ReportMemoryLeaksOnShutdown auch unter MacOS funktioniert. Der Fehler liegt also in der falschen Erwartung einer Funktionalität hervorgerufen durch ein Versäumnis in der Dokumentation. Diese Art der Fehlerbehebung kommt häufiger vor, als manche vielleicht denken. Das habe ich auch schon bei Autoherstellern erlebt.

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