Menu coché

Bonjour;
J'ai une application avec un menu dont certaints éléments sont des éléments à cocher.
A mon avis tout le monde ferai comme moi, c'est à die faire ces évenments:
.L'options de menu "coche" est séléctionnée
+ L'option de menu "coche" est cochée
-> [img]/epicentre/images/%%GRAEMLIN_URL%%/special.PNG[/img]: Décocher l'option de menu "coche"

.L'options de menu "coche" est séléctionnée
+ (négation)L'option de menu "coche" est cochée
-> [img]/epicentre/images/%%GRAEMLIN_URL%%/special.PNG[/img]: Cocher l'option de menu "coche"

Or j'ai l'impression que les 2 événements sont éxécuté lorsque l'ont séléctionne l'item.

Serai-ce un bug de MMF2.

Je pense que c'est le fonctionnement normal de MMF2 : lorsque le premier événement est exécuté, l'option est décochée, donc la deuxième condition devient vraie et le deuxième événement est exécuté lui aussi.

Il faudrait passer par un flag ou une variable :

.L'option de menu "coche" est séléctionnée
+ L'option de menu "coche" est cochée
-> mettre variable toto à 0

.L'option de menu "coche" est séléctionnée
+ L'option de menu "coche" est décochée
-> mettre variable toto à 1

. L'option de menu "coche" est séléctionnée
+ Variable = 0
-> Décocher l'option de menu "coche"

. L'option de menu "coche" est séléctionnée
+ Variable = 1
-> Cocher l'option de menu "coche"

Espérons que Francois pourra implémenter un Else dans MMF3, ça rendrait bien service.

Ou encore plus simple avec un flag :

.user clicks on "case"
-> toggle internal flag 0

.flag 0 of "case" is on
-> case cochée

.flag 0 of "case" is off
-> case décochée

<div class="ubbcode-block"><div class="ubbcode-header">En réponse à:</div><div class="ubbcode-body"> Espérons que Francois pourra implémenter un Else dans MMF3, ça rendrait bien service.</div></div>
ben si j'attends après MMF3 c'est pour avoir un meilleur flux logique sinon je ne vois même pas ce qui justifie une version 3.

<div class="ubbcode-block"><div class="ubbcode-header">En réponse à:</div><div class="ubbcode-body">ben si j'attends après MMF3 c'est pour avoir un meilleur flux logique sinon je ne vois même pas ce qui justifie une version 3. </div></div>
Oh rien, mis à part peut-être les 1200 autres options dans la liste des choses à faire dans MMF2. [img]/epicentre/images/%%GRAEMLIN_URL%%/laugh.gif[/img]

un meilleur flux logique ??? O_o je vois vraiment pas ce qu'il pourrait y avoir de plus logique que des evenements qui s'execute un par un, après c'est à toi de rendre l'ordre de tes événements logique [img]/epicentre/images/%%GRAEMLIN_URL%%/wink.gif[/img]

crois moi si tu avais moyen d'executer 2 evenements l'un à coté de l'autre, ca serais carrement le bordel pour déterminer si l'un ou l'autre est terminé avant de passer à autre chose...

"des evenements qui s'execute un par un" ça n'est pas ce que j'appelle un flux logique. Il faut des branchements conditionnels, des boucles, des sauts, des passages de paramètres, des variables, des tableaux, des fonctions, des classes, du code réutilisable, etc...
Ca existe plus ou moins sur MMF mais avec des contraintes sérieuses ou du bidouillage qui relève du hack.

Evidemment il ne s'agit pas de transformer MMF en editeur de code C++ mais il y a quand même des améliorations à apporter au niveau de l'aspect développement.
Parce que à part ça moi j'ai déjà tout ce qui me faut avec MMF2 (quoiqu'il me manque un bon objet 3D et un text blitter avec fonte proportionnelle)

mmmm

ca s'appel plutot des flux alternatifs... les boucles existent déjà, les variables, les tableaux, le code réutilisable également, et tout sans aucun bidouillage...

Ensuite MMF n'utilise aucun langage donc tu ne peut lui demander de pouvoir écrire les programmes de la même manière qu'en dark basic ou autre. MMF utilise son propre système logique qui ressemble quand même un peu au C++, en tout cas bien plus que Virtools [img]/epicentre/images/%%GRAEMLIN_URL%%/wink.gif[/img]

Ola Brovic... j'utilise les 2 : MMF et Virtools. Chacun à sa méthode et le résultat est correct dans les 2 cas. Pour le second, tu oublies de dire que dès que tu fais un projet commercial sérieux, cette entreprise te propose une aide pour la fin de ton dev pour "cleaner" et "améliorer" ton code, en codant, par exemple certaines fonctions qui n'existent pas... Prouvant ainsi que le produit ne permet qu'un protypage d'un jeu ! Jusqu'à preuve du contraire un lien dans l'arbre logique ou une ligne d'évènement est exactement identique en terme logique... Ceux qui font de l'electronique ou de la programmation industrielle ne sont pas perdu devant un arbre logique, Pour les autres c'est pas de la tarte ! ces "autres" sont un peu moins perdus avec MMF !!!
Même le second produit cité a un pipeline de traitement de données et a même une architecture 2 axes entre les conditions et les évènements/actions qui n'est pas forcément simple à comprendre pour quelqu'un qui ne maitrise pas les grafcets ou la prog sur PB100 (automate programmable).
avec MMF, on peut créer réellement un jeu qui tient la route, est stable, en peu de temps, sans une formation à 300 euros la journée !!!!
Il est peut être encore à améliorer mais quel logiciel ne s'améliore pas pour rester un acteur incontournable ???
MMF est de trés loin, la solution évidente au développement de jeux 2d. Et puis après le sdk est là pour faire un peu plus si ton niveau de prog le permet !
Mais n'oublions pas que MMF s'est défini à partir de la game click, et donc, à une philosophie trés simple (et pas simpliste) qui permet, rapidement, facilement, logiquement, de faire tout type de jeu pour lequel il a été conçu.
Tout ce qui est simple pour l'utilisateur est une réellement extrêmement complexe à gérer ! et à ce sujet, on peut tous tirer notre chapeau à Clickteam !

Si j'avais trouvé mieux je ne serais pas ici, hein [img]/epicentre/images/%%GRAEMLIN_URL%%/wink.gif[/img] .
Mais le problème à l'origine du thread c'est qu'une tâche aussi basique que cocher/décocher une case peut devenir un casse-tête à cause du fonctionnement interne particulier de MMF. C'est un des cas de figure où paradoxalement tu paies cette simplicité au prix fort. Et c'est encore plus compliqué avec un menu switch type boutons radio. J'ai qd même trouvé une méthode zen qui évite de recourir à une brouette d'events et de variables mais elle est moins fiable qu'avec la méthode des fastloops (qui reste qd même "lourde" à mettre en place) :
Cases à cocher/switch

Avec des "if" "then" "else" imbriqués et + de contrôle sur la boucle de MMF on éviterait pas mal de prises de tête de ce genre.

la meilleure solution reste le toggle flag... après en fonction de ce flag, on peut faire pas mal de choses.

Avec pas mal de recul, on arrive aussi à utiliser les groupes intelligemment ce qui permet les programmes très complexes pas si complexe que ca à coder [img]/epicentre/images/%%GRAEMLIN_URL%%/wink.gif[/img]