IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Lazarus Pascal Discussion :

[2.2.2] Exécution : pourquoi les ItemMenus ne pâlissent pas quand-ils sont désactivés


Sujet :

Lazarus Pascal

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre confirmé
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Mars 2006
    Messages
    59
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : Bâtiment

    Informations forums :
    Inscription : Mars 2006
    Messages : 59
    Par défaut [2.2.2] Exécution : pourquoi les ItemMenus ne pâlissent pas quand-ils sont désactivés
    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!

  2. #2
    Membre Expert

    Homme Profil pro
    Directeur de projet
    Inscrit en
    Mai 2013
    Messages
    1 650
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Directeur de projet
    Secteur : Service public

    Informations forums :
    Inscription : Mai 2013
    Messages : 1 650
    Par défaut
    Bonjour,

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

    Salutations

  3. #3
    Membre confirmé
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Mars 2006
    Messages
    59
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : Bâtiment

    Informations forums :
    Inscription : Mars 2006
    Messages : 59
    Par défaut
    Bonjour!

    Citation Envoyé par Guesset Voir le message
    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!

  4. #4
    Membre Expert

    Homme Profil pro
    Directeur de projet
    Inscrit en
    Mai 2013
    Messages
    1 650
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Directeur de projet
    Secteur : Service public

    Informations forums :
    Inscription : Mai 2013
    Messages : 1 650
    Par défaut Messages perdus
    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

  5. #5
    Membre confirmé
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Mars 2006
    Messages
    59
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : Bâtiment

    Informations forums :
    Inscription : Mars 2006
    Messages : 59
    Par défaut
    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!

  6. #6
    Membre Expert

    Homme Profil pro
    Directeur de projet
    Inscrit en
    Mai 2013
    Messages
    1 650
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Directeur de projet
    Secteur : Service public

    Informations forums :
    Inscription : Mai 2013
    Messages : 1 650
    Par défaut Tricher
    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

Discussions similaires

  1. Exécutable : tous les VIs ne fonctionnent pas
    Par KNouch dans le forum LabVIEW
    Réponses: 10
    Dernier message: 07/05/2012, 08h07
  2. Pourquoi les navigateurs n'interpretent pas XML par defaut ?
    Par SkyBack dans le forum XML/XSL et SOAP
    Réponses: 3
    Dernier message: 03/11/2010, 12h22
  3. Pourquoi les navigateurs n'interpretent pas XML par defaut ?
    Par SkyBack dans le forum Performance Web
    Réponses: 1
    Dernier message: 02/11/2010, 17h29
  4. Réponses: 0
    Dernier message: 21/07/2009, 13h35
  5. Réponses: 4
    Dernier message: 13/03/2007, 12h19

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo