Button gibt sich selbst bei klick frei

[QuickAndDirty]

Hallo,
Folgender Kontext:
ich habe nen eine Listbox mit Listboxitems und auf den Listboxitems sind Speedbuttons welche beim antippen dafür sorgen das ein das entsprechende Listenelement gelöscht wird.
Es wird freigegeben.
Das hat lustigerweise in Delphi XE8 funktioniert.
In Delphi Berlin kommt nun aber nach dem "Click Ereignis" noch ein Code für "TriggerTouchanimation", Das führt dann wohl zu einer Zugriffsverletzung da der Button schon mit dem Listenelement freigegeben ist.
Der Button kommt durch einen Style auf das ListenItem. Kann es sein das Delphi XE8 die Controlls aus Styles hat länger leben lassen?

Wie auch immer ich wollte das Problem lösen in dem ich eine WindowsMessage an einen Messagelistener im Formular schicke, in der Hoffnung das die Message erst abgearbeitet wird wenn die touchanimation beendet ist.
Nun mal die Frage. Funktionieren Wondowsmessages in Android und IOS?
Wie teile ich Einer multiplattform App mit , das sie was machen soll nach dem alles andere was gerade auf dem stack liegt erledigt ist?

[himitsu]

Entweder verzögert löschen.
Timer oder siehe TForm.Release

Oder den nachfolgenden Code überspringen.
Abort

[QuickAndDirty]

:(
Also es gibt keine MessageQueue mehr?

Abort hört sich gut an. Das funktioniert bei Datenbanken ja auch.

Gibt es sowas wie Release für alle GUI objekte? Weil ein ListItem ist ja nun keine TForm.

Edit:
Jo es gibt ein Release für TListitem, gleich mal testen

Edit2:
Release scheint zu funktionieren. Vielen Dank!

Edit3: Realease scheint wohl nur unter Windows zufunktionieren.

[Der schöne Günther]

Zitat:

Zitat von QuickAndDirty (Beitrag 1359365)

Wie teile ich Einer multiplattform App mit , das sie was machen soll nach dem alles andere was gerade auf dem stack liegt erledigt ist?

TThread.Queue(..) ?

[QuickAndDirty]

Zitat:

Zitat von Der schöne Günther (Beitrag 1359378)

TThread.Queue(..) ?

Würde Thread.Queue() sicherstellen das die Animation beendet ist bevor das element freigegeben wird?

Edit:
Thread.Queue bringt auch den Segmentationfault(11) nach dem Freigeben.

Edit:
Was ist ein PresentationProxy?

Ich muss irgendwie die Nachricht PM_START_TRIGGER_ANIMATION and den PresentationProxy verhindern :( versuche jetzt den Ansatz mit "abort"

[QuickAndDirty]

Zitat:

Zitat von himitsu (Beitrag 1359376)

Entweder verzögert löschen.
Timer oder siehe TForm.Release

Oder den nachfolgenden Code überspringen.
Abort

"Abort" würde auf Android erstmal funktionieren. Es ist eine komische Lösung.

Das "Freigeben" passiert in einer Refresh Methode die halt erst alles abräumt und dann alles neu lädt...die selbe Methode benutze ich beim erstellen des Formulars.
Ich wünschte es gäbe einen offiziellen weg sowas anzuschieben ohne Abort.

[himitsu]

TThread-Queue führt nichts verzögert aus, wenn es im Hauptthread aufgerufen wird ... man müsste erst einen anderen Thread starten ud dann darin das Queue aufrufen :stupid:

[QuickAndDirty]

Zitat:

Zitat von himitsu (Beitrag 1359421)

TThread-Queue führt nichts verzögert aus, wenn es im Hauptthread aufgerufen wird ... man müsste erst einen anderen Thread starten ud dann darin das Queue aufrufen :stupid:

Ok. Deswegen hat es nicht geklappt.
Wäre die Methode zu bevorzugen?
1.Thread erzeugebn der dazu bestimmt ist die Oberfläche(Zwei TlistViews) neuzuladen.
2.Thread ausführen.
3.Im Thread Synchronisation mit Hauptthread auslösen durch Übergabe der Reload methode an TThread.Queue(nil,Reload);

Wieso hat das alles unter Delphi XE8 geklappt? Gab es da die Touch-Animationen noch nicht?

[QuickAndDirty]

Hab in meiner "commonfunctions" unit folgendes gebaut

Delphi-Quellcode:

TQThread = Class(TThread)
private
Public
  ThreadMethod:TThreadMethod;
  Procedure Execute;Override;
end;
Procedure QueueMethod(aThreadMethod:TThreadMethod);

implementation


Procedure QueueMethod(aThreadMethod:TThreadMethod);
var aThread:TQThread;
Begin
  aThread := TQThread.Create(true);
  aThread.FreeOnTerminate := True;
  aThread.ThreadMethod := aThreadMethod;
  aThread.Resume;
End;


{ TQThread }

procedure TQThread.Execute;
var i,j :integer;
begin
  For i := 0 to 10 do j := j+1;// Damit der Kompiler die Zeile darunter nicht wegoptimiert.
  TThread.Queue(nil,ThreadMethod);
end;

Rufe das wie folgt auf

Delphi-Quellcode:

procedure TAuswahlView.Reload;
begin
  QueueMethod(self.InternalReload);
end;

Funktioniert erschreckend gut. Bis jetzt. Werde es mal auf weitere bereiche ausdehnen und testen.Vielleicht funktioniert dann wieder alles wie es soll.

[Der schöne Günther]

Zitat:

Damit der Kompiler die Zeile darunter nicht wegoptimiert

Was :shock:

[himitsu]

Wegoptimieren wird er das nicht. Sooooo schlau ist der nun auch nicht, daß er den Thread drumrum einfach weglässt.

Pssst: http://www.delphipraxis.net/179193-t...der-queue.html -> siehe Antwort #9 und hier nochmal die Kurzfassung davon:

Delphi-Quellcode:

TThread.CreateAnonymousThread(procedure
  begin
    Queue(AThread, procedure
      begin
        // mach hier irgendwas verzögert
      end);
  end).Start;

[Der schöne Günther]

Wahrscheinlich hat er in der Debug-Fassung keinen Haltepunkt da Inlining nicht deaktiviert wurde und der Compiler das inlined? :gruebel:

[QuickAndDirty]

Zitat:

Zitat von Der schöne Günther (Beitrag 1359755)

Wahrscheinlich hat er in der Debug-Fassung keinen Haltepunkt da Inlining nicht deaktiviert wurde und der Compiler das inlined? :gruebel:

hm Der halte punkt war halt beim kompilieren weg(grün) .

[QuickAndDirty]

Zitat:

Zitat von himitsu (Beitrag 1359754)

Wegoptimieren wird er das nicht. Sooooo schlau ist der nun auch nicht, daß er den Thread drumrum einfach weglässt.

Pssst: http://www.delphipraxis.net/179193-t...der-queue.html -> siehe Antwort #9 und hier nochmal die Kurzfassung davon:

Delphi-Quellcode:

TThread.CreateAnonymousThread(procedure
  begin
    Queue(AThread, procedure
      begin
        // mach hier irgendwas verzögert
      end);
  end).Start;

Ich mache wirklich alles im Hauptthread.... hab erst recht spät erkannt das es da noch an anderen Stellen Probleme gibt...wenn Sachen länger dauern...da steht noch ein größerer Umbau an. Ich wollte es halt möglichst leicht zu debuggen haben...

Queue funktioniert also bei mir bis her wie erwartet. Danke!

[Mavarik]

Die Lösung hierfür heißt OnIdle...

Ich habe mir hierfür eine eigene FreeAndNIL -> ArcFreeAndNil -> KillLater geschrieben....

[QuickAndDirty]

Theoretisch wäre wohl sowas wie ein JobScheduler das richtige, welcher dann alles was man Queued in Application.OnIdle ausführt.Aber ich hab jetzt erstmal die Thread Geschichte.

[Mavarik]

Zitat:

Zitat von QuickAndDirty (Beitrag 1359810)

Theoretisch wäre wohl sowas wie ein JobScheduler das richtige, welcher dann alles was man Queued in Application.OnIdle ausführt.Aber ich hab jetzt erstmal die Thread Geschichte.

Ja TIdleWorker... Von Sir Rufo

[QuickAndDirty]

Das mit TThread.Queue hatte zwar auf Windows geklappt und auch auf Android in allen Fällen außer in einem....

Nach dem Create eines Formulars wird der Style einer Componente nicht korrekt gerändert.
TThread.Queue(Liste.ApplyStyleLookup) löst das problem auf Windows
Aber in Android bleibt es falsch gerändert...

Hab dann nen JobScheduler für arme geschrieben...(hab deinen Post nicht gleich gesehen)
Damit funktioniert es wenn man

TJobScheduler.Queue(Liste.ApplyStyleLookup);
TJobScheduler.Queue(Application.ProcessMessages);

ausführt.

Es kann auch sein das nicht alles davon notwendig ist. Leider ist es ja unmöglich Erkenntnis darüber zu bekommen warum ein Style unvollständig gerändert wird.
Der JobScheduler arbeitet im Application.Idle Ereignis wenn die Liste mehr als null Jobs hat.

Warum sind so einfache Dinge, so schwierig zu lösen?

[himitsu]

Zitat:

Delphi-Quellcode:

TJobScheduler.Queue(Application.ProcessMessages);

In ProcessMessages werden die OnIdle-Ereignisse aufgerufen. (zumindestens im Windows)
Macht das hier dann einen Kreisaufruf? :stupid: (eine Endlosschleife wäre auch cool ... je nachdem, wann man den Job aus der Queue entfernt)

[Harry Stahl]

Wir hatten doch schon mal so ein ähnliches Problem, wo ich eine Lösung mit TTask.Run vorgeschlagen hatte, funktioniert die hier nicht?

Siehe hier:
http://www.delphipraxis.net/1358288-post7.html

[QuickAndDirty]

Zitat:

Zitat von Harry Stahl (Beitrag 1359867)

Wir hatten doch schon mal so ein ähnliches Problem, wo ich eine Lösung mit TTask.Run vorgeschlagen hatte, funktioniert die hier nicht?

Siehe hier:
http://www.delphipraxis.net/1358288-post7.html

Leider nein. Habe das ja so gemacht...In Windows geht es in Android geht es nicht.
In Android funktioniert nur die Application.OnIdle Lösung;

[Harry Stahl]

OK, wenn das auch unter den mobilen Plattformen verwendet werden soll, ist das Beispiel ungünstig, da man dann eh besser vom Parent-Object die vorgesehen Lösch-Funktionen verwendet.

Ein direktes Free des ListboxItems hat wegen AutoRefCount unter den mobilen Plattformen sowieso nicht die erwünschte Auswirkung. Hier müsste man also ListBox1.items.delete(index) verwenden. Das wird dann anders als unter Windows behandelt und das System kümmert sich dann um die tatsächliche Entfernung des Eintrags zum passenden Zeitpunkt.

Ich hab es mal kurz hier getestet, diese Variante funktioniert hier unter Windows und Android, hier das Android-OnTap-Event:

Delphi-Quellcode:

procedure TForm46.lbiTap(Sender: TObject; const Point: TPointF);
var
  tt: TTask;
  lbi: TListBoxItem;
begin
  if TFmxObject(Sender).Parent is TListBoxItem then
  begin
    lbi := TListBoxItem(TFmxObject(Sender).Parent);
    
    TTask.run (procedure
    begin
      TThread.Synchronize(NIL, procedure
      begin
        Listbox1.Items.Delete(lbi.Index);
      end);
    end);
  end;
end;

[QuickAndDirty]

Es ist kein directes Free.
Es ist ein ein implizites free durch clear.