Nix mit plattformübergreifend...

[Rued]

Zitat von Olli73:

Der Code gehört in einen Timer oder Thread (an synchronize denken).

Ich taste mich an die App-Programmierung mit dem PDF-Dokument "Mobile App Entwicklung mit DELPHI" heran, da mir keine hilfreiche Literatur bekannt ist und mir niemand einen entsprechenden Tipp geben konnte.

Wenn ich besagtes Dokument nach "synchronize" durchsuche bekomme ich keinen Treffer. Gleiches gilt für "Thread". Ich versuche es mal mit Timer-Komponenten.

Was ist mit dem Versprechen plattformübergreifender Programmierung? Frage geht nicht an Dich. Dir danke ich für Deinen Hinweis.

[gubbe]

Plattformübergreifend heißt ja nicht, dass alles, was auf dem Desktop unter Windows funktioniert hat, sich so 1:1 auf Mobilsysteme übertragen lässt.
Android mag es gar nicht, wenn die Benutzeroberfläche längere Zeit nicht reagiert. Das "Application.processmessages" ist allerdings auch schon unter Windows keine gute Lösung mehr.
Insofern sollte man es plattformübergreifend anders lösen. Wie vorschlagen mit Threads, aber für Deinen Anwendungsfall könnte tatsächlich der Timer geeignet sein.

Es gibt dazu einen Blog-Eintrag von Marco Cantu:

https://blog.marcocantu.com/blog/201...d_threads.html

[TurboMagic]

Hallo,

naja, mehrheitlich geht es schon plattformübergreifend, aber es gibt manchmal Dinge die auf einer
Plattform erlaubt sind bzw. gut funktionieren und auf einer anderen leider verboten sind oder nicht
gut klappen.

Zum Beispiel sind modale Dialoge (also solche die man zuerst bearbeiten muss bevor man weiter im
Programm was tun kann) unter Windows erlaubt und nicht unüblich, unter Android aber verboten.
Versucht man entsprechende Aufrufe in seiner App wird man dann eine Exception "ernten".

=> 1:1 ist nicht immer alles möglich, auch wenn schon recht viel geht.

Noch ein Tipp zu deiner App: versuche es erst mal mit einem TTimer hinzubekommen, das ist unkritischer
als Threads und leichter zu lernen. So leistungsfähig Threads sind, so einfach kann man sich mit denen
auch ins Knie schießen und sucht sich dann den Wolf nach sporadischen Fehler ab...

Application.ProcessMessages sollte man soweit irgend möglich auch vermeiden.
Das kann im ungünstigsten Fall auch zu einer Endlosschleife führen, weil es ggf. das Event in dem
man gerade drin ist erneut auslöst. Zumindestens unter Windows kann das vorkommen, da zum Zeitpunkt des
Auslösens des Events die Benachrichtigung dazu immer noch im Briefkasten ist. Keine Ahnung warum die das
so programmier haben, ist aber so.

Falls du dich mit Threads beschäftigen möchtest: suche nach TThread und sorge tunlichst dafür dass alle
GUI Ausgaben aus dem Thread heraus (also alle die aus der Execute Methode stammen) mittens Synchronize
erfolgen. Sonst wird deine App sporadisch ab und zu abstürzen.

[QuickAndDirty]

Es geht plattformübergreifend, wenn man das plattformübergreifende Framework benutzt. Alles was man "zufuß" programmiert muss man natürlich selbst plattformübergreifend gestalten.

[AuronTLG]

Nur noch ergänzend als Erklärung:

Generell ist es so, dass Android und IOS im Gegensatz zu Windows grundsätzlich asynchron laufen, d.h. der Hauptthread kann dort nicht unterbrochen werden. Dies hat verschiedenste Konsequenzen, wie z.B. dass die App bei Nutzung von diversen Dialogs wie ShowMessage auf Android oder IOS weiterläuft oder wie erwähnt ShowModal und Sleep aus denselben Gründen im Hauptthread nicht funktionieren.
Deswegen hier auch die Empfehlungen, das Ganze über einen Thread oder Timer zu lösen.

[TurboMagic]

Zitat von Rued:

Zitat von Olli73:

Der Code gehört in einen Timer oder Thread (an synchronize denken).

Ich taste mich an die App-Programmierung mit dem PDF-Dokument "Mobile App Entwicklung mit DELPHI" heran, da mir keine hilfreiche Literatur bekannt ist und mir niemand einen entsprechenden Tipp geben konnte.

Wenn ich besagtes Dokument nach "synchronize" durchsuche bekomme ich keinen Treffer. Gleiches gilt für "Thread". Ich versuche es mal mit Timer-Komponenten.

Was ist mit dem Versprechen plattformübergreifender Programmierung? Frage geht nicht an Dich. Dir danke ich für Deinen Hinweis.

Shon mal hier geschaut?
https://delphi-books.com/en/index.html

z. B. Expert Delphi enthält auch einiges zum Thema mobile Programmierung,
auch wenn der originale Autor leider zwischenzeitlich verstorben ist. Aber bei der 2. Edition ist ja Marco Cantu dabei.
Ich kenne nur die erste Edition, kann also leider nicht sagen was beri der zweiten verbessert wurde.

[Rued]

Ich danke für Eure Hinweise, TurboMagic für den Link auf die Literatur. Komme wohl um englischsprachige Werke nicht herum - wenn ich noch motiviert bin, mich nach 30 Jahren hobbyproggen für Windows umzustellen.
Momentan bin ich nur genervt, da selbst die einfachsten Dinge nicht funktionieren:

Delphi-Quellcode:

setlength(rf,anz);
for a := 0 to  anz -1 do rf[a] := a;
  azufmix(rf);
  for a := 0 to  anz -1 do begin
   n:= rf[a];
  MessageDlg(Spain[n].SpruchES, TMsgDlgType.mtConfirmation,
    [
      TMsgDlgBtn.mbYes,
      TMsgDlgBtn.mbNo,
      TMsgDlgBtn.mbClose
    ], 0, procedure(const AResult: TModalResult)
            begin
              case AResult of
                mrNo: showmessage(Spain[n].SpruchDE);
                mrClose:exit;
              end;
            end );
end;

Der case-Code wird völlig ignoriert. Selbst wenn ich den showmessage- und den exit-Befehl auslager, geht es nicht:

Delphi-Quellcode:

...
              case AResult of
                mrNo: zeig := true;
                mrClose:raus := true;
              end;
            end );

    if raus then break;
    if zeig then showmessage(Spain[n].SpruchDE);
...

Mit zwei Timern habe ich es mit dem Ergebnis versucht, dass genau ein spanischer Ausdruck und nach gewünschten 5 Sekunden die deutsche Übersetzung angezeigt werden - dann ist Schluss.

Code im Start-Button

Delphi-Quellcode:

//array rf wird entsprechend Record-Größe für Ausdrücke gefüllt
setlength(rf,anz); for a := 0 to  anz -1 do rf[a] := a;
//Array wird gemischt
azufmix(rf);
  for a :=0 to anz-1 do begin
    wo := rf[a];
    LSpain2.Text := Spain[wo].SpruchES;
   Timer1.Enabled := true;
end;

Code im Timer1

Delphi-Quellcode:

Timer2.Enabled := true;
Timer1.Enabled := false;

Code im Timer2

Delphi-Quellcode:

LGer2.Text := Spain[wo].SpruchDE;
Timer2.Enabled := false;

[gubbe]

Bei dem Beispiel mit MessageDLG wird vermutlich direkt die ganze For-Schleife durchlaufen. Der Dialog wartet ja nicht auf die User-Unterkation, sondern ruft asynchron die anonyme Procedure auf, die Du als letzten Parameter übergibst. Da ist die For-Schleife schon nicht mehr aktiv.
Von daher kann auch das Exit nichts mehr bewirken, da es nicht innerhalb der For-Schleife ausgeführt wird. Es verlässt nur die anonyme Procedure, macht also letztlich gar nichts. Ob Showmessage hier funktionieren sollte, weiß ich nicht, aber auch das wird vermutlich nicht modal ausgeführt, also nicht warten, bis der Benutzer OK gedrückt hat.

Man muss mobil wirklich ganz umdenken und es Event-Basiert lösen. Das heisst hier: Keine For-Schleifen in denen Benutzereingaben erwartet werden. Dialog-Boxen sind auch hier nicht ideal. Da würde ich eher auf dem Form die Texte darstellen und mit einem Weiter-Button dann die nächsten etc.

Beim Timer-Beispiel ist es ähnlich. Du rennst mit der For-Schleife direkt das ganze Array durch. Wenn Du darin den Timer auf True setzt, blockiert das nicht die weitere Ausführung der For-Schleife.
Am Ende wird der Timer nur einmal aufgerufen.

Am besten merkst Du Dir global den aktuellen Index (das a bei der For-Schleife),setzt den Text und startest dann den Timer. Innerhalb des Timers erhöhst Du die Nummer und setzt den nächsten Text usw. bis das Maximum erreicht ist.

[AuronTLG]

Zitat:

setlength(rf,anz);
for a := 0 to anz -1 do rf[a] := a;
azufmix(rf);
for a := 0 to anz -1 do begin
n:= rf[a];
MessageDlg(Spain[n].SpruchES, TMsgDlgType.mtConfirmation,
[
TMsgDlgBtn.mbYes,
TMsgDlgBtn.mbNo,
TMsgDlgBtn.mbClose
], 0, procedure(const AResult: TModalResult)
begin
case AResult of
mrNo: showmessage(Spain[n].SpruchDE);
mrClose:exit;
end;
end );
end;

Das hier geht in die richtige Richtung, ist aber nicht ganz richtig gedacht. Wie erwähnt kann der Hauptthread in Android nicht blockiert werden, d.h. der MessageDlg hält die App nicht an, wodurch die Schleife einfach weiterläuft.
Die asynchronen Dialoge mit Rückgabemethode funktionieren so, dass sie angezeigt werden während der Quelltext weiter ausgeführt wird und die Rückgabemethode genau dann ausgelöst wird, wenn der Nutzer mit dem Dialog interagiert hat.
Dementsprechend muss der nächste Schritt immer in der Rückgabemethode ausgelöst werden. Das erfordert, wenn man eine Art Schleifendurchlauf erreichen will, etwas Umdenken.

Zitat:

//array rf wird entsprechend Record-Größe für Ausdrücke gefüllt
setlength(rf,anz); for a := 0 to anz -1 do rf[a] := a;
//Array wird gemischt
azufmix(rf);
for a :=0 to anz-1 do begin
wo := rf[a];
LSpain2.Text := Spain[wo].SpruchES;
Timer1.Enabled := true;
end;

Ähnliches Problem wie oben: Die Schleife ist in Sekundenbruchteilen durchgelaufen, in welchen derselbe Timer anz - 1 mal wieder und wieder auf Enabled gesetzt wird, wodurch er dennoch genau einmal ausgelöst wird.
Ähnlich wie oben muss der nächste Schritt immer beim auslösen des Timers durchgeführt werden.

[QuickAndDirty]

Ich habe das gefühl du strukturierst dein Programm wie ein Kommandozeilen-Programm bzw,. Konsolen-Programm.

Die GUI ist aber Ereignis getrieben, bzw. Thread getrieben.

Das Application Framework hat eine Message Queue.

Wenn du "MessageDlg" oder "showmessage" aufrufst ist das Non-Blocking. Das heißt, die Funktion hinterlegt in der Warteschlange, dass du nen Dialog angezeigt haben willst, wie der konfiguriert wird und welcher Code danach ausgeführt werden soll.

Wenn dein For-Schleifen Code abgearbeitet ist und das Ereignis das deinen Code aufgerufen hat abgearbeitet ist, dann wird das nächste Ereignis aus der Warteschleife abgearbeitet, und irgendwann kommen dann deine Dialoge dran.

Der Timer setzt wenn er enabled wird alle so und so viel millisekunden eine Nachricht auf die Warteschlange, dass ein Ereignis ausgeführt werden soll.


Du musst nicht eine "Eingabe-Verarbeitung-Ausgabe-Wiederholen" struktur anlegen, denn das Framework hat das alles schon. Das Framework erlaubt dir Callback Proceduren zu hinterlegen , sogenannte Events.