Android: Seltsames verhalten von TCommonCustomForm.Hide;

[Harry Stahl]

Ich verwende unter Android eine "modale" Form per

Delphi-Quellcode:

Form := TMeineForm.create (NIL);
Form.ShowModal (procedure (AResult: TModalresult)
begin
   if AResult = mrOK then begin
     ....
   end;
   Form.disposeof;
end);

Bei einer so angezeigten Forms ist es dann so, wenn man auf OK oder Abbrechen klickt (mrOK, mrCancel), dass in FMX.Forms versucht wird, die Form wieder unsichtbar zu machen:

Delphi-Quellcode:

procedure TCommonCustomForm.Hide;
begin
  FVisible := False;
  if Active then
    Screen.NextActiveForm(Self);
  if not (csDesigning in ComponentState) then
    FWinService.HideWindow(Self); // hier kracht es, bzw. funktioniert nicht beim ersten aufruf
  DoHide;
  if GetFullScreen then
  begin
    FFullScreen := True;
    SetFullScreen(False);
  end ;
end;

Dabei kracht es dann bei "FWinService.HideWindow(Self);" (Schutzverletzung).

Wenn ich statt (des empfohlenen) "Form.DisposeOf" dann "Form.free" verwende, geht es ohne Schutzverletzung, aber die Form wird erst geschlossen, wenn ich ein weiteres mal auf den Schalter klicke (Schalter haben kein OnTab oder OnClick-Event, alles nur über Modalresult-Werte).

De facto wird auch dann 2 x mal der Code innerhalb der anonymen Prozedur ausgeführt.

Übrigens ist da kein Unterschied bei dem Punkt, dass man 2 mal auf OK oder Abbrechen klicken muss, wenn ich die Form nicht modal, sondern einfach nur per "Show" anzeigen lasse und die notwendigen Arbeiten im OK-Event durchführe.

Auf der anzuzeigenden Form ist auch nichts besonderes, 2 Schalter und eine Listbox, wo man einen Eintrag auswählen kann.

Sehr seltsam das.

Hat evtl. hier schon mal was ähnliches erlebt, bzw. hat eine Idee wie man das beheben könnte.

[Harry Stahl]

Na, "modale" Aufrufe von Forms (selbst über den Weg der anonymen Prozedur) mögen wohl IOS und Android nicht so sonderlich.

Ich habe jetzt einen Weg gefunden, der auf beiden Plattformen fehlerfrei funktioniert:

1. Kein modaler Aufruf, sondern "Form.show"

2. Bevor die gerade angezeigt Form wieder unsichtbar gemacht werden soll ("Hide"), zunächst die vorausgehende Form (z.B. Mainform) wieder in den Vordergrund bringen (Mainform.bringtofront) und dann erst das Hide aufrufen.

Dann funktioniert es auch mit einem Klick auf den Schaltern und es gibt keine doppelten Aufrufe...

[Schokohase]

In einem Event-Handler oder Callback-Handler würde ich niemals die Instanz entsorgen, die diesen Event/Callback-Handler aufruft.

Das ist IMHO eigentlich Basiswissen.

[Harry Stahl]

Zitat:

Zitat von Schokohase (Beitrag 1426034)

In einem Event-Handler oder Callback-Handler würde ich niemals die Instanz entsorgen, die diesen Event/Callback-Handler aufruft.

Das ist IMHO eigentlich Basiswissen.

Da ja blockierende Dialoge unter Android nicht erlaubt sind, gibt es eine überladene Version von Showmodal, die Funktion wird dann asynchron ausgeführt (d.h. nach Aufruf der Funktion geht die Programmausführung in der aufrufenden Prozedur direkt weiter, da wäre es dann zu früh, den Dialog wieder freizugeben).

Insofern erschien es mir durchaus denkbar, dass per "DisposeOf" (welches ja quasi ein Refcount unter den Mobilen Plattformen ist) der Aufruf auch innerhalb der anonymen Prozedur erlaubt ist, da die tatsächliche Freigabe erst erfolgt, wenn keine Bezüge mehr bestehen.

Jedenfalls hatte ich das auch so in verschiedenen Code-Schnippseln dargestellt gefunden (Stack overflow).

Aber ist wohl doch nicht ganz so unproblematisch.

Jedenfalls führt der hier beschriebene Weg führt auch zu einem ordnungsgemäßen Ergebnis:

http://docwiki.embarcadero.com/RADSt...l_Dialog_Boxes

Also gar kein DisposeOf (oder free) aufrufen, sondern im Close-Event der Form .cafree für Closeaction setzen.

[Schokohase]

Zitat:

Zitat von Harry Stahl (Beitrag 1426048)

Insofern erschien es mir durchaus denkbar, dass per "DisposeOf" (welches ja quasi ein Refcount unter den Mobilen Plattformen ist) der Aufruf auch innerhalb der anonymen Prozedur erlaubt ist, da die tatsächliche Freigabe erst erfolgt, wenn keine Bezüge mehr bestehen.

Da wirfst du aber einiges durcheinander.

Wenn keine Bezüge mehr bestehen, dann wird unter ARC die Instanz freigegeben. Das ist richtig. Kann man damit vergleichen, dass der Korb mit Inhalt entsorgt wird, wenn keiner mehr den Korb kennt.

Wenn man

Delphi-Quellcode:

DisposeOf

aufruft, dann wird der Inhalt des Korbs entsorgt aber nicht der Korb selber. Aber woher weißt du das der Inhalt nicht mehr benötigt wird, wenn der Callback (von dem Korb) aufgerufen wird? Eben, kannst du nicht wissen also solltest du den Korb-Inhalt auch in Ruhe lassen.

Es ist wie gesagt ganz einfach:
In Event-Handlern oder Callback-Handlern wird niemals die aufrufende Instanz freigegeben oder disposed.

Hält man sich nicht daran, dann bekommt man dieses Verhalten. Wenn es trotzdem funktionieren sollte, dann ist das nicht Können, sondern Glück.

Du könntest natürlich auch das Problem beschreiben, was du mit diesem

Delphi-Quellcode:

DisposeOf

lösen möchtest, dann könnten wir dir dafür eine Lösung vorschlagen.