Canvas multiple ou seul pour différents boutons et events ?

[Ar-S]

En développement de mon prog, j'ai eu besoin de créer plusieurs boutons.
J'ai commencé par ne créer qu'un seul Canvas "Menu" regroupant les différentes images de menu.
Il me suffisait ensuite de capturer les coordonnées de la souris pour déterminer le choix de l'utilisateur et l'image de "rollover".
ça marchait bien mais je me suis dit que c'était un peu tordu à la longue.

J'ai donc rebroussé chemin et ai créé 1 canvas par choix du menu.
Je n'avais plus à me soucier des coordonnées de la souris, super ! ... Mais par la suite je me suis aperçu que c'était bien plus redondant de gérer les eventtype() de chaque canvas...

J'ai donc décidé de repartir sur 1 seul canvas gérant les event selon la position de la souris lors d'un clique.

Et vous ?
Êtes vous plus de style 1 canvas par bouton ou 1 canvas pour tous les boutons ?

N'hésitez pas à développer.

[Backup]

perso j'aurai séparé
diviser pour mieux régner (j'aurai meme probablement utilisé les Images, et gestion souris en callback a l'ancienne

pour les Event, ma fois, faut faire avec , c'est juste une question de "propreté" de code ; ça se gere
comme pour le multifenetrage ...

[graph100]

Pour moi ce sera 1 canvas par boutons / menu / autres bidules...
y a qu'a voir la série de gadget que je me suis faite

Mais pour éviter que ça deviennent le souk, fait des procedures standards pour chaque type de boutons.
Ils ne devraient pas être si différent à gérer.

[cederavic]

Ca ne risque pas de poser des soucis de perf s'il y a trop de canvas?

[Ar-S]

Ca ne risque pas de poser des soucis de perf s'il y a trop de canvas?

C'est aussi ce que je me suis dit. Le nombre de StartDrawing(CanvasOutpu(xxx)) s'en trouve démultiplié.
Mais j'avoue que je suis amoureux de ce gadget. Même si au final je préfère n'en utiliser qu'un pour simuler de multiples boutons.

[Backup]

Ca ne risque pas de poser des soucis de perf s'il y a trop de canvas?

c'est pourquoi j'aurai fait ça a base d'images ...

[Ar-S]

Ca ne risque pas de poser des soucis de perf s'il y a trop de canvas?

c'est pourquoi j'aurai fait ça a base d'images ...

Tu veux dire de ButtonImage ?

Le dynamisme et la gestion des events des canvas est tout de même bien pratique. Cet aprem je vais re-coder les boutons "valider/Annuler/sauver/charger" en un seul canvas. (oui j'ai ajouté un bouton annuler.)

[Backup]

Ca ne risque pas de poser des soucis de perf s'il y a trop de canvas?

c'est pourquoi j'aurai fait ça a base d'images ...

Tu veux dire de ButtonImage ?

non d'images ... c'est pas toi qui utilisai la Lib du soldat inconnu pour Skiner Fenetre et gadget ?

[Ar-S]

Si

Mais les boutons impliqués changent de taille et disparaissent si inutilisable selon l'interaction de l'user. Donc la libskin ne se prête pas trop à ce genre d'exercices. Et ça entrainerait un jeu d'images plus grosse.

Du coup je suis reparti sur le dessin des boutons dans le canvas. J'avais mis de coté les structures. Grave erreur... du coup je suis en train de structurer tout ça. C'est long mais ça s'éclaircit.
J'ai aussi écrit sur papier les différents effets de chaque action, ce qui clarifie aussi grandement les choses.

[Backup]

Si

Mais les boutons impliqués changent de taille et disparaissent si inutilisable selon l'interaction de l'user

Resizeimage()

et il doit etre possible d'utiliser un flag pour afficher ou pas une image

[G-Rom]

perso , j'utiliserais des images, le canevas ne serais que la cible de rendu, cela permettrais d'avoir plusieurs type de cibles : écran , sprite , etc...