Discussion :

[Clad3]

Bonjour à tous !

Avant que mon projet ressemble a une horreur et que je ne m'en sorte plus, je me suis décidé a demander votre avis !

Je posséde un application ( un jeu ), et pour le moment , tout mes objets sont pêle-mêle , ca ne ma pas posé beaucoup de problème jusqu'a lors, car il n'est pas arrivé que deux objets soit ensemble, l'un couvert par l'autre par exemple ...

Je me demande tout d'abbord une chose , faut-il que dés que un objet/classe a repercuté une action suite a un input précis, que j'indique a la classe qui gère les input, que celui-ci n'a plus lieu d'etre traité par une autre classe .... ( je pense que oui , sauf si vous avez des contre exemple ... )

De plus, je suis en 2D , et je n'ai pas de hiérarchie devant/derrière ... ce qui commence a me poser pas mal de problème ; par exemple, ( je suis entrain de travailler a l'éditeur de niveau ), celui-ci comporte diverse fenetres ( je gérer tout a la main , pas de bibli de fenetrage ) , donc en gros mes fenetre ( un rectangle pour résumé ) se balade sur l'ecran .
1er pb -> Si j'ai 2 fenetre qui se chevauche, pour le moment, les input vont allé a la première présente en mémoire ... pas bon ca :p
2eme pb -> SI je clique sur la fenetre, et que le clique a un effet ( pas pour le moemnt mais ca va venir ) sur la carte dessiné en dessous ..je suis mal

En gros ma question est : dois-je bricoler la gestion de l'ordonencement des input ( en priant pour que les problèmes de ce genre soit peu nombreux et se régle tous au cas par cas ... ) Ou alors dois-je mettre en place un système plus robuste ? Et sur ce point ...j'attend vos idées, car je n'en ai pas ...

Merci .

[Laurent Gomila]

A priori (je peux me tromper) je pense que l'input doit aller en priorité au contrôle qui a le focus, puis remonter de parent en parent jusqu'à arriver au contrôle qui n'a pas de parent (la fenêtre principale). Je pense aussi que chaque contrôle peut choisir de stopper la propagation de l'input à son parent, s'il le désire.

Enfin faudrait etudier des GUI existant pour ce genre de systèmes.

[Clad3]

Hum, j'ai deja fait ceci :
Si une classe doit avoir SEULE le focus c'est possible, j'ai prévu cela dans le design .
Par contre, dans le cas ou j'ai 3-4 fenêtres qui se baladent dans mon apli, aucune d'entre elle na le focus plus qu'une autre donc je suis bloqué :/

Sinnon l'idée de la propgation enfant -> parent me parait a creuser ^^ ( je vais voir comment ca s'implemente ... car pour le moment je ne garde pas de trace des parents dans mes objets ... c'est peut-etre un tord ... )

Je pense aussi que chaque contrôle peut choisir de stopper la propagation de l'input à son parent, s'il le désire

Ca renvoie a ma première question, enfin je eput faire en sorte que oui/non ca stoppe la propagation de l'input, mais justement, je me demande si c'est du cas par cas, ou si je peux me permettre de stopper la propagation de l'input dés qu'il est traité .

[Laurent Gomila]

Par contre, dans le cas ou j'ai 3-4 fenêtres qui se baladent dans mon apli, aucune d'entre elle na le focus plus qu'une autre donc je suis bloqué :/

Ca ne gêne pas, rien ne t'empêche de donner le focus à la dernière cliquée. C'est a priori ce que font tous les systèmes de GUI.

Ca renvoie a ma première question, enfin je eput faire en sorte que oui/non ca stoppe la propagation de l'input, mais justement, je me demande si c'est du cas par cas, ou si je peux me permettre de stopper la propagation de l'input dés qu'il est traité .

Je pense que c'est à traiter au cas par cas, typiquement le contrôle choisit de renvoyer ou non l'évènement selon le type de celui-ci (en appelant ou non recursivement sur le parent, ou en renvoyant un booléen, etc...).

[Clad3]

Bon, je m'en suis sorti
Pas certain que ce soit de la meilleur facons ... mais le problème est réglé .

Je suis parti sur l'hypothése que je vais régler ca au cas par cas .

Voila ce que j'ai fait :

- Tout d'abord j'ai remis un peu d'ordre dans ma gestion des Inputs, de facons a signaler a mon programme dés qu'une action avait été prise ( je ne vois toujours pas de contre-exemple, ou un input serait traité par deux objet distinct, sans que ceux-ci ne soit reliés ) .
- Ensuite, je me suis basé sur un ordre de priorité pour toute les fenetres .
En pratique, leur rang dans le vecteur contenant toute les fenetres . Donc celle en premier recoit les input, si elle les traite , elle le signale, il ne seront donc pas retraité par les fenetre suivantes . Si elle ne les traitent pas, les fenetre suivante ont la possibilité de le faire, si c'est le cas , elle le font et on les place en premier dans le vector des fenetres ( et hop, au premier plan ^^ )

C'est un peu du bricolage, mais je pense ( *espère* serait un terme plus approprié ) que je n'aurais pas a reproduire ce shéma beacoup de fois plus tard .... tout au plus une fois, dans mon programme principale, qui gérera tout les "objets" de mon jeu .

Voila ... problème *résolu*