Re : Choix de structure pour une IHM

[R_Thomas]

Bonjour,

Je m'essaye actuellement au Xcontrol et tente une IHM un peu poussé que mes habituelles.

Comme vous pouvez le voir dans mon programme j'utilise les splitters pour passer d'une "fenêtre" `l'autre lorsque l'on appuie sur les graphiques.

Ma question est la suivante : faut il que je gère aussi ces mouvements comme des Xcontrols ? dans ce cas cela signifierait gérer tout la face avant en tant que Xcontrol non ? ou dois je tout laisser comme avant ?

Je cherche juste à partir dans la meilleure direction pour la suite de mes développements.

Merci d'avance !

(normalement toutes les pièces se trouve dans le dossier)

[R_Thomas]

Up

[Desruelle_luc]

Salut,

il n’y a pas l’ensemble du code, mais si je comprends bien tu veux faire un effet « slider » « swipe screen », pour décaler ta page avec un effet de mouvement et tu veux le gérer avec des splitters.

Je réponds non à la question : je gère aussi ces mouvements comme des Xcontrols 

Pour info, pour le principe, je pense qu’il y a plus simple, tu as une fenêtre, qui a une origine, tu changes programmatiquement l’origine. Je te conseille de regarder le projet de

http://chrislarson.me/content/chris-larson/labview-vi-ipad-style-page-swiping

même si l'ensemble du code n'est pas à prendre en exemple.

J'ai codé une IHM qui gére plusieurs pages avec une gestion tactile, comme le soft de Chris.

La gestion n'est pas un objet graphique, de type XControl, mais un process (ou actor ou acteur ou programme informatique) qui gére, en parallèle du reste du code, les actions (états, message) que lui produit ue autre structure.

Donc structure producteur-consommateur, avec un structure "event" dans le code IHM du Main, qui produit sur détection d'actions de l'utilisateur sur l'IHM, par exemple par FIFO, à une deuximée boucle while en // (le deuximème process) des actions. Sur les actions, la deuxième boucle va gérer le "déplacer l'origine" de la fenêtre".

Tu peux le coder facilement sur un base de QMH (ou QDMH), cf les templates de projet de LabVIEW.

J'ai commencer, il y a quelques temps, à encapsuler le code de gestion "swipe" dans un code autonome, type Actor de l'actor framework, mais je n'ai pas terminé, par manque de temps, mais il faudrait... si je le termine je te le donne...

A+

[R_Thomas]

Merci Luc, oui tu as bien compris mon besoin.

Il y a effectivement un nouveau concept pour moi dans ce projet, dont des choses à reprendre !

Je vais analyser ca !

Mais pour résumé, j'aurai 2 options :

- la première (qui s'approche le plus de ce que j'essaye d'utiliser), structure producteur/consommateur avec une boucle de détection des évenements utilisateur + une boucle de gestion de l'IHM et une autre que j'utilise en générale pour l'acquisition de donnée

- la deuxième qui consiste à utiliser un VI juste pour la gestion de l'IHM en utilisant d'autre sous VI (cf. projet de Chris)

C'est bien ca ?

Si tu le finis, effectivement ton code m'intéresserait pour voir comment tu gères ca !! 🙂

Merci !

[Desruelle_luc · Accepted solution]

Salut le code de chris n'est pas modulaire. L'idée est bonne mais difficielement réutilisable.

je te conseille

---

- la première (qui s'approche le plus de ce que j'essaye d'utiliser), structure producteur/consommateur avec une boucle de détection des évenements utilisateur + une boucle de gestion de l'IHM et une autre que j'utilise en générale pour l'acquisition de donnée

---

Structure QDMH :

> structure event, (Driven) sur détection mouse move, génére des Messages (State + Data) par Queue FIFO

> structure gestion IHM type Dequeue

Il ne me reste plus qu'à finir mon exemple de code....

A+

[Desruelle_luc]

et comme écrit ouadji 

kudos

[R_Thomas]

Merci beaucoup 😉

Je crois que Ouadji à trouvé la meilleure méthode pour passer le message 😄

[Desruelle_luc]

vrai!!!