Discussion :

[fernet]

Bonjour!
J'ai un jeu d'échec ou quand L'utilisateur commence à jouer, des ItemMenus sont désactivés comme
(changer de joueur) ou de (niveau) ou de (réglage). Alors si je clique sur rejouer, ces ItemMenus ne pâlissent
pas tout de suite. System:W10 32 bits.
Chose curieuse:
-- Si je déplace la souris sur les Items désactivés ils ne palissent pas.
-- Si je clique sur le premier Item tous les Items désactivés pâlissent.
-- Si je clique sur n'importe qu'elles autres Items, seulement celui-ci pâlis.
-- Après avoir cliqué sur un Item, le passage de la souris sur les autres, les fait pâlir.
-- Le redimensionnement de la fenêtre les fait tous pâlir.
-- La même chose ce produit si je change le nom de L'Item(caption).

Alors je ne comprends pas ce qu'il se passe, je viens de passer de la version
Lazarus 2.2.0 à 2.2.2 et j'avais le même problème avant, les ItemMenus ont
besoin d'un coup de main pour changer.

P.S. En réactivant les Items, tout vas bien, il noircisse tous.

Fernand, Merci!

[Guesset]

Bonjour,

Ca sent un besoin de Application.ProcessMessage ou de refresh/repaint.

Salutations

[fernet]

Bonjour!

Ca sent un besoin de Application.ProcessMessage ou de refresh/repaint.

J'ai essayé l'événement OnChange avec Application.ProcessMessage et cà rien changé.

Code :

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

1
2
3
4
5
 
procedure Tprincip.menuseChange(Sender: TObject; Source: TMenuItem; Rebuild: Boolean);
begin
  application.ProcessMessages;
end;

J'ai essayé aussi l'événement OnDrawItem du menu avec Application.ProcessMessage
et je ne vois plus mon menu.

J'ai essayé aussi l'événement OnDrawItem de l'Item avec Application.ProcessMessage
et je ne vois plus mon Item.

Là je ne comprends toujours pas ce qui ce passe! Dans L'aide LCL de l'unité Menus il
parle de:

TMainMenu.ItemChanged
Performs actions needed when a menu item has been changed.
Declaration
Source position: menus.pp line 433
protected procedure TMainMenu.ItemChanged;
Description
Calls MenuChanged when a menu item has been changed in the widgetset class.

Fernand, Merci!

[Guesset]

Bonjour,

Comme la plupart des événements sont activés par des messages, placer Application.ProcessMessage dans un OnChange c'est un peu descendre de vélo pour se regarder pédaler.

Il faut le mettre en dehors d'un gestionnaire d'événement, vraisemblablement à un endroit où il y a beaucoup de calculs non visibles (i.e. sans affichage). Pour éviter de trop ralentir ces calculs, il est possible de limiter le nombre de Application.ProcessMessage par un compteur ou une mesure de temps (tous les 1/10 s par exemple).

Salutations

[fernet]

Bonjour!

L'instruction Application.ProcessMessage est déjà placé à des endroits stratégiques de mon jeu pour ne pas
nuire à l'exécution.
Il faut dire que ce jeu est une conversion Delphi du menu Outils vers Lazarus qui s'est fait sans problème
après avoir éliminé (AutoHotkey) que Lazarus supporte pas.

Sous Delphi 10.3.2 je n'avais aucun problème avec les menus. Une autre chose que J'ai remarqué est que
si je place le pointeur sur un Item désactivé son arrière-plan ne vire pas au bleu pâle comme ceux qui sont
activés.

Fernand, Merci!

[Guesset]

Bonjour,

Pourtant le fait que le comportement se normalise au changement la taille de la fenêtre montre que les messages de changement de taille émis par l'OS entraînent également le traitement des autres messages en attente.

Concernant les messages de l'OS, l'application est obligée de les recevoir et de les traiter (même si le traitement peut être : "j'en ai rien à faire"). Les messages internes ne bénéficient pas de cette priorité.
Bon, je triche un peu car beaucoup de messages internes ne sont pas si internes que cela et passent par l'OS. Mais dans le cas d'un système de développement multi OS le taux de messages purement internes augmente pour ne pas avoir trop à se soucier des particularismes de chaque système d'exploitation.

Il serait tentant - et très laid - de tester un changement de taille fenêtre par programmation pour voir si la normalisation a lieu.

Faute de voir le code il me sera difficile d'aller plus loin.

Salutations

[fernet]

Bonjour,

Il serait tentant - et très laid - de tester un changement de taille fenêtre par programmation pour voir si la normalisation a lieu.

Faute de voir le code il me sera difficile d'aller plus loin.

Salutations

Bonjour!
Bien sûr si rien n'y fait, je vais essayer quelque chose de ce genre.

Pour l'instant j'ai ouvert un autre jeu converti de Delphi à Lazarus et pour tester, J'ai désactivé quelques ItemMenus.
Il s'avère que celui-là fonctionne très bien. Pourtant il ne contient aucun (Application.ProcessMessage).

Mon jeu d'échec lui, j'ai enlevé du DFM la ligne (AutoHotkeys = maManuel) parce qu'il me renvoyait cette erreur et
je devais fermer Lazarus car plus rien ne fonctionnait.



Je ne sais pas si ça a pu causer une erreur de conversion dans le TMainMenu, J'ai ouvert les deux LFM pour
comparer et il me semble tous les deux correctes.

Fernand, merci!

[Guesset]

Bonjour,

Dès qu'une application passe en attente (idle mode ou attente d'un événement clavier, souris ou autre) les messages sont traités y compris ceux en attente. Il n'y a alors pas besoin de Application.ProcesMessage explicite.

En général, le problème apparaît lors de phases de calcul intensif et se trouve accentué avec une montée en priorité du processus.

J'ai un peu l'impression de tourner en rond car cette explication, qui me semble assez sûre, ne peut engendrer une solution que sur un code que je ne connais pas.

Bonne chance.

[fernet]

Bonjour!

En général, le problème apparaît lors de phases de calcul intensif et se trouve accentué avec une montée en priorité du processus.
J'ai un peu l'impression de tourner en rond car cette explication, qui me semble assez sûre, ne peut engendrer une solution que sur un code que je ne connais pas.

Oui je comprends et je ne veux surtout pas abusé. Sur mon bureau J'ai la version Delphi compilé du même code et
dès que je clique sur Rejouer les Items désactivés pâlissent.

Dans cette procédure j'émet un son d'abord, puis je désactive les Items et je me dirige dans engage.

-- Si c'est au logiciel à jouer, il calcul son move rencontrant de temp en temp des Application.ProcessMessages et
une fois complété il fait son move et redonne la main à l'utilisateur. Tout ce temp le menu reste noirci.

-- Quand c'est à l'utilisateur à jouer il roule entre (Repeat sleep(100);Application.ProcessMessage; Until bon);
jusqu'à ce que l'utilisateur clique sûr une pièce à jouer. Tout ce temp le menu reste noirci.

Dès qu'il a choisi son move le logiciel demande une confirmation et là les Items pâlissent.

P.S. J'ai alterné a toutes les 500 millisecondes, activé, désactivé les Items dans mon Ttimer et je les vois flasher à l'écran.

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
 
procedure Tprincip.joulogClick(Sender: TObject); // Voir "engage" pour debuter
begin
 jeu := true;flh := true;
 mt.log := true;oto := false;pcs := false;pice := 0;
 cpo := clblack;cpl := clwhite;automa.Checked := false;
 if vefmtg
 then begin
   if motpas(1) and ((mt.jou <> 0) or mt.bar[1] or motpas(8))
   then begin
     sonchg;                                    anumen(true); //desactive les Items menu
     engage;plcjou;
     princip.timer.Enabled := true; end;end;
 sonchg;fleche;                                 remenu;       //reactive les Items menu
 anubts;post := 0;automa.Checked := false;
 jeu := false;oto := false;cpl := clblack;cpo := clwhite;echicq;
end;

Fernand, Merci.

[Guesset]

Bonjour,

Je ne suis pas sûr de comprendre. Dans la boucle du timer, est-ce que les (dés)activations fonctionnent ?

Je pense que le Application.ProcessMessage dans l'attente d'un mouvement utilisateur n'est pas nécessaire car le programme ne semble pas avoir grand chose à faire alors. Le retirer pour voir.

La procédure engage utilise une bibliothèque d'ouvertures ou quelque chose de plus lourd (plus de calculs) ?

Même si le code donné est très fragmentaire, il y a quelques interrogations :

• atom.checked est mis à false avant et après le test : quelque chose peut le modifier entre temps ?
• les menus sont liés à des actions d'une ActionList ?
• à quoi sert le true de anumen (le code de cette procédure pourrait être intéressant) ?

Salutations

[fernet]

Bonjour!
Oui dans le timer ça fonction, il flache, donc il passe de noirci a pâli à noirci a pâli etc.

La procédure d'attente de l'utilisateur est un peu plus sophistiqué que je l'es indiqué. C'est la procédure
(depare) qui est en bas ici. En somme cette procédure fonctionne avec le OnClick de la fiche principale, et
quand L'utilisateur clique, le OnClick calcule la position du pointeur et place les coordonnées dans nbx nby
puis met coo = true. (Depare) enregistre ces coordonnées et attend les coordonnées du deuxième clique
qui est la casse ou vas la pièce. Donc pas de calcule Juste de l'attente.

Mon interface graphique est tout fait à la main, dessiné sur le Canvas de la fiche principale. Je n'utilise
aucun Objet pour les pièces et les casses de l'échiquier et c'est pourquoi que Application.ProcessMessage
est nécessaire.

Automa.Checked peut être activé en n'importe quel temps dans un autre menu(Option).

Anumen(false) c'est quand l'utilisateur joue contre un humain et non contre Projechec, les flèches qui
recule ou avance la partie ne sont pas désactivées.

Mes menus ne sont liés a rien d'autre que leur Onclick.

D'après ce que je peux voir les Items ne pâliront pas tant que le OnClick qui désactive le menu n'est pas
complété. C'est comme un clic de souris, l'action se produit seulement quand on relâche le bouton. Bien
sûr si le menu est sollicité de l'extérieur, il pâliront aussi.

J'ai rajouté une capture d'écran en espérant que tout ça t'aidera à comprendre.

Fernand. Merci!

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
52
53
54
55
56
57
58
59
60
61
 
procedure anumen(oke:boolean); // Les fleches qui reculent ou avancent la partie
begin                          // ne sont pas desactive quant un joueur jou contre un autre joueur
 with princip do
 begin
   rejoue.Enabled := false;
   diffic.Enabled := false;
   insjou.Enabled := false;
   stajou.Enabled := false;
   stapro.Enabled := false;
   passer.Enabled := false;
   nouvel.Enabled := false;
   montag.Enabled := false;
   if oke
   then begin
     ariere.Enabled := false;
     avance.Enabled := false;
     debute.enabled := false;
     finter.Enabled := false; end;
   posdeu.Enabled := false;
end;end;
procedure depare; // Controle de la piece selectionnee par l'humain
 var kal:tie;
begin
 if cp.sui
 then eck[0] := not echhum(dph,pcw)
 else eck[0] := not echlog(dpl,pcw);
 if oto and (cp.oto = cp.nbt) and not cp.bri and tessht
 then bon := true
 else begin
   princip.Cursor := CrHandPoint;
   kal[1] := 0;kal[2] := 0;kal[3] := 0;kal[4] := 0;
   repeat
     net[0] := kal;
     if kal[1] <> 0
     then situer(kal);
     setoue;affich(true);
     if (rpt[0,5] <> maxi) or (rpt[1,5] <> mini)
     then begin
       if rpt[0,5] <> maxi
       then flechs(co1,axe[rpt[0,1],rpt[0,2],1],axe[rpt[0,1],rpt[0,2],2],axe[rpt[0,3],rpt[0,4],1],axe[rpt[0,3],rpt[0,4],2])
       else flechs(co2,axe[rpt[1,1],rpt[1,2],1],axe[rpt[1,1],rpt[1,2],2],axe[rpt[1,3],rpt[1,4],1],axe[rpt[1,3],rpt[1,4],2]);
       repare; end;
     coo := false;bon := false;ote := false;srt := false;kal[3] := 0;kal[4] := 0;
     repeat
       Sleep(100);
       application.ProcessMessages;
       if coo
       then begin
         coo := false;
         if (kal[1] = 0) or ((pcm^[nbx,nby] < 0) and cp.sui) or ((pcm^[nbx,nby] > 0) and not cp.sui)
         then begin kal[1] := nbx;kal[2] := nby; end
         else begin kal[3] := nbx;kal[4] := nby; end;
         if kal[1] <> 0
         then situer(kal);
         affich(true); end;
     until ote or srt or bon;
   until srt or bon;
   vers63(0);
   princip.Cursor := CrArrow; end;
end;

[Guesset]

Bonjour,

Bel écran.

Ce serait bien de faire de anumen une méthode de la fiche principale (Tprincip. ?), il aurait un accès direct aux TMenuItem sans with princip do.

Ensuite il est possible de mettre un application.ProcessMessage en fin de anumen (normalement c'est inutile)

Code PAS :

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
procedure Tprincip.anumen(oke : boolean);    // Les fleches qui reculent/avancent la partie
begin                                        // ne sont pas desactive si joueur contre joueur
   rejoue.Enabled := false;
   diffic.Enabled := false;
   insjou.Enabled := false;
   stajou.Enabled := false;
   stapro.Enabled := false;
   passer.Enabled := false;
   nouvel.Enabled := false;
   montag.Enabled := false;
   if oke then begin
      ariere.Enabled := false;
      avance.Enabled := false;
      debute.Enabled := false;
      finter.Enabled := false; 
   end;
   posdeu.Enabled := false;
   Application.ProcessMessages;
end;

Dans depare :

• kal[3] := 0; kal[4] := 0; est répété. C'est normal ?
• A quoi sert le sleep(100) ? C'est une boucle d'attente d'un événement ?
• Le CrHandPoint change bien le curseur ? (c'est géré par un message)
• coo, ote, srt et bon sont modifiés indépendamment de depare ? Par quoi : une commande clavier, un clic ou autre ?

Salutations

[fernet]

Bonjour!
En réalité dans mon menu les parenthèse sont des Items toujours désactivés, ils servent de séparateur et j'ai
utilisé le OnClick de la double parenthèse pour désactivé les Items. Alors dans JoulogClick je calle la procédure
ParentClick(Sender,true) mais ça n'a rien changer. Je ne sais pas si c'est la bonne façon de faire.

J'ai essayé aussi un Application.ProcessMessage dans (anumen) et ça fonctionne pas.

Kal[3] et kal[4] sont les coordonnés de la case ou va aller la pièce. Si le move choisi est faux ils sont remis à
zéro, mais la pièces choisi reste sélectionné.

Ote et srt sont gérés par le menu Arrêter/Quitter et serve comme le menu l'indique.

La procédure (situer(kal)) dans (depare) vérifie le move choisi et met bon = true quand il est bon.

Le CrHandPoint fonctionne, il est changé immédiatement.

Le sleep(100) sert juste pour économiser l'énergie.

Si ta machine est sous Windows, je pourrais t'envoyer mon jeu par message priver et tu pourrais
l'essayer pour voir ce qu'il fait.

Fernand. Merci!

[Guesset]

Bonjour,

Oui je suis sous Windows. Il est possible de m'envoyer un message via le site. Si, en l'occurrence cela ne va pas je fournirais une autre adresse.

Est-ce que le programme a tourné en mode debug avec un point d'arrêt dans anumen ? il y passe ?

Salutations

[fernet]

Bonjour!
Tout ce que j'ai trouvé pour résoudre le changement des ItemsMenus, c'est de rajouter Application.Minimize suivi de Application.Restore.
De cette façon les Items pâlissent et les Captions sont changés. Cependant çà émet un petit scintillement.

J'ai remarquer aussi que si on clique sur un ItemMenu désactivé, l'exécution s'arrête. Ce petit programme avec le code source explique
et démontre ce qui se passe avec TMainMenu quand ces Items sont désactivés ou changés. Il est très court et simple car il contient que
des (OnClick) et trois autres petites procédures.

Alors si quelqu'un veut bien prendre le temps de le regarder, ce serait apprécié.

Fernand, Merci!

TesMenu.zip

[acaumes]

Bonjour,

Alors si quelqu'un veut bien prendre le temps de le regarder, ce serait apprécié.

Je viens de regarder. chez moi (W11/ Lazarus 2.2.4/ FPC 3.2.2) tout a l'air de bien fonctionner (les menus sont activés désactivés dès que je clique ou dès clic sur la forme selon le menu utilisé)

Rien ne se passe au clic sur un menu désactivé...

Cordialement

[fernet]

Bonjour,
Je viens de regarder. chez moi (W11/ Lazarus 2.2.4/ FPC 3.2.2) tout a l'air de bien fonctionner (les menus sont activés désactivés dès que je clique ou dès clic sur la forme selon le menu utilisé)
Cordialement

Bonjour!
Il ne faut pas cliquer sur la forme, car à ce moment là, le ProgressBar disparait et les ItemsMenu pâlissent.

Si tu clique sur désactive(attente) par exemple, le ProgressBar s'active mais les ItemsMenu n'ont pas
pâlis, portant ils ont été désactivés et le beep vien du OnChage du TMainMenu. Maintenant si tu clique
sur le premier ItemMenu a gauche ils vont tous pâlir et le ProgressBar va s'arrêter de défiler. Poutant
le programme est toujours dans la boucle Repeat..Until de la procédure (attent) et le ProgressBar devrait
continuer de défiler.

En tout cas c'est ce qui se passe chez moi avec (W10 Lazarus 2.2.2 et FPC 3.2.2).

Fernand.

[fernet]

Bonjour !
En fin de compte j'ai remplacé Application.Minimize suivi de Application.Restore par un simple ShowMessage et les ItemMenus
désactivés pâlissent tous avant que le message apparaisse.
Bien sur ça ne résout pas le problème mais pour mon jeu d'échecs ça fonctionne très bien.



Merci ! Fernand.