Nix mit plattformübergreifend...

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