Discussion :

[bizulk]

Voilà je voulais avoir vos avis sur la façon de construire une transition (QSignalTransition)

Contexte :
J’ai une classe Metier qui contient :

• Les états QState
• La machine,
• Les transitions
• une fonction qui construit le graphe d’états
• Les fonctions “métier” exécutées lors des transitions ou dans l’entrée d’un état.

J’ai une interface qui communique avec la classe métier notamment via un signal ‘état(val)’.

J’ai dans mon modèle une transition qui prend pour trigger, le signal ‘état(val)’, et pour action une fonction qui prend ‘val’ comme paramètre.

Qt propose de réimplémenter QAbstractTransition::onTransition(QEvent) pour coder l’action. Seulement cette fonction s’exécute dans l’espace de la transition et non dans la classe métier.
Le signal QAbstractTransition::triggered() ne propage pas -hélas- l’évènement.

Donc comment attaquer proprement la classe métier depuis la transition ?

La solution de la ‘callback C’
Subclasser QSignalTransition, pour founir un accesseur sur le parent et la fonction à exécuter.
Ca marche mais pour être générique il faut que :
tous les parents aient un seul type de base (QObject *)
La signature de la fonction est unique (donc on utiliserait une QList<QVariant>) pour être le plus générique possible.

Utiliser un accesseur
Le trigger n’envoir plus d’information. La classe métier se connecte au signal triggered et utilise un accesseur sur l’interface. Gros problème : si l’objet métier et l’interface s’exécute de façon asynchrone. Il faut alors installer un mécanisme de synchronisation pour assurer l’intégrité des informations, et plus de choses encore si l’on veut éviter une perte d’information.

La réémission d’un signal triggered()
Pour être générique et éviter l’implémentation en pagaille de signaux/slot, il faudrait émettre un signal avec QList<QVariant>avec en arguments les valeurs envoyés par le trigger. Il pourrait être émit en place du signal triggered().
C’est ma solution préférée, car finalement on ne fait que propager l’évènement vers le récepteur.
Seulement triggered() étant un signal je reimplemente onTransition() pour envoyer un autre signal triggered(QList<QVariant>) auxquel je connecterais un slot de la classe métier.

Revoir la modélisation
Etudié mais pas possible de faire autrement.

S'il le faut le placerai du code.
Merci pour toute réponse.

[yan]

Si tu sous classe la transition, tu peux récuperer les paramètres avec l'event.
http://qt.developpez.com/doc/latest/...e-signalevent/
http://qt.developpez.com/doc/latest/...ition/#details

Mes préférence :
- callback
- Signal. Pour le connect thread safe.
- reemettre un event vers le QObject cible. Le QObject sera appelé par le bon thread
- un lambda avec std::function<>

Mon préféré est le dernier. Car tu y fait ce que tu veux.

[bizulk]

J'ai donc subclassé pour ré-implémenter onTransition() qui émet un signal triggered(args), args étant les arguments envoyés par le signal à l'origine de la transition.
Ca fonctionne,
Merci pour ta réponse.
Au passage peux-tu expliquer "lambda std::function<>".

[yan]

Au passage peux-tu expliquer "lambda std::function<>".

C'est une nouveau du nouveau standard :
http://en.wikipedia.org/wiki/C%2B%2B...nd_expressions

En gros c'est une callback avec un context. C'est dans la même idée que les inner classe & co de java et C#.

J'ai mis des exemples exploitant cela dans QExtend :
http://projets.developpez.com/projec.../dev/src/c++0x