Discussion :

[Anselme45]

Bonjour,

J'ai une application pour Android qui a plusieurs Tab dans un TabControl correspondant chacun à un écran.

Quand l'app fait une requête qui récupère des données dans une base de données distante, il est fait appel à un thread spécifique pour permettre la séquence suivante: Android affiche un écran1 avant la requête > la requête est lancée et Android affiche un écran2 avec une animation vue que l'opération peut prendre un certain temps > Quand la procédure Delphi utilisée pour faire la requête et traiter les données retournées est terminée, Android affiche un écran3.

Cette approche a toujours fonctionné mais voilà que l'app doit aujourd'hui choisir entre 2 requêtes différentes. Dès lors, on remplace la ligne de code "proc1;" appelant une procédure par un "if condition then proc1 else proc2;" pour lancer l'une ou l'autre requête et là cela fonctionne le plus souvent mais parfois, l'app reste bloquée sur l'écran servant à afficher l'animation (avec l'animation qui s'est arrêtée) et il faut toucher l'écran pour que le 3ème écran s'affiche normalement.

A remarquer que le problème n'apparaît pas parce que c'est une proc plutôt que l'autre qui serait appelée... On manipule l'app en appelant la proc1, la proc2, un nombre de fois variable et après un "certains" temps, l'app garde à l'affichage l'écran avec l'animation à l'arrêt (le problème peut apparaître tout de suite ou après plusieurs dizaine de requêtes)...

Après de multiple recherche sur le web et différents essais (comme utiliser des variables locales dans le thread plutôt que des variables globales (qui pourraient être utilisées au même moment par des thread différents), le problème persiste.

Ci-dessous, le code qui a fonctionné et qui fonctionne avec le if la plupart du temps mais parfois non... Est-ce que quelqu'un a une idée?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
 
procedure TForm1.GetData(Ref:string);
var
 mybool, mybool2:boolean;
begin
 mybool:=UneVariableGlobale;
 
 Tthread.CreateAnonymousThread(
  procedure
   begin
    try
 
     Tthread.Synchronize(TThread.CurrentThread,
     procedure
      begin
 
 
       FloatAnimation1.Enabled:=False;
       FloatAnimation2.Enabled:=False;
 
       TabControl1.ActiveTab:=tabLoading;  //Ecran avec l'animation 
 
       FloatAnimation1.Enabled:=True;
       FloatAnimation2.Enabled:=True;
      end);
 
     if mybool then mybool2:=proc1(Ref) //Quand il n'y avait que "mybool2:=proc1", le code fonctionnait
      else mybool2:=proc(Ref);
 
    finally
     Tthread.Synchronize(TThread.CurrentThread,
     procedure
      begin
       FloatAnimation1.Enabled:=False;
       FloatAnimation2.Enabled:=False;
 
       if mybool2 then
        begin
          TabControl1.ActiveTab:=tabResult; //Ecran3a affichant résultat
          proc3;
        end
       else
         TabControl1.ActiveTab:=tabNoResult; //Ecran3b sans résultat
 
      end);
     end;
 
   end).Start;
 
 
end;

Merci d'avance

[ShaiLeTroll]

Déjà un Thread qui commence par un Synchronize ... on peut se poser des questions !

Quel est la partie hors de Synchronize, je n'arrive pas à le repérer je déteste cette syntaxe brouillonne des threads anonymes.
Ah si proc1 et proc

Et si c'est le changement de proc, c'est peut-être le contenu de ces procs

Déjà attention avec la base de données, l'objet connection n'est pas utilisée en même temps par le MainThread et le thread secondaire ? certains composants ne sont pas thread-safe, il faut une connexion par thread.

J'aurais plutôt fait un TNotifyEvent pour gérer Proc3 mais j'ignore comme cela peut s'écrire avec cette syntaxe car là si il y a une exception, cela invoque proc3, est-ce pertinent si proc1 et proc n'ont pas retourné de valeur, je différencierais le traitement par un try except et un try finally

[Anselme45]

Et si c'est le changement de proc, c'est peut-être le contenu de ces procs

Merci pour ta réponse,

Au final, le problème n'avait rien à voir avec la gestion du thread, mais bien avec le contenu des proc... Entre la sortie du Thread et le code de l'une des proc, il y avait 2 fois l'appel à l'écran 3... Pourquoi est-ce que cela a longtemps fonctionné et que lors de la reprise du code en y ajoutant l'appel d'une nouvelle proc, l'affichage reste bloqué sur l'écran d'attente? Très certainement un problème de timing...

Effectivement ces threads "anonyme" n'ont pas non plus ma préférence, mais bon quand on récupère un code à modifier, on fait avec... Par contre, j'ai essayé de compiler ce code programmé en Delphi 10.4.2 en Delphi 11 et j'ai constaté que ce formalisme de thread anonyme ne passe plus à la compilation...