Identifier les actions du ruban

Bonjour,

est-il possible d'identifier les actions du ruban autrement que par le nom fourni lors de la configuration ?

Objectif: Injecter cette identification dans une fonction (select case)


Mon use-case:
Le bandeau contient 2 boutons; ici j'imagine que le 1° bouton, en partant de la gauche, est identifié 1 et le 2° est identifié 2
Tous les boutons pointent sur le même code, celui qui suit:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

... ... ...   Dim idRibbonCmd As Byte   Dim fctToRun As String   Select Case idRibbonCmd   Case 1   fctToRun = "fonction_1"   Case 2   fctToRun = "fonction_2"     Case Else   MsgBox "Erreur à traiter ?"   End Select     mainWrapper (fctToRun)   ... ... ...

---

Explication: mainWrapper --> Factorisation d'un traitement puis appel de la fonction passée en paramètre.
Pour l'exemple je ne parle que de 2 boutons mais en réalité, il y en a plus. Toutes les fonctions (boutons) ont un traitement commun et je veux éviter de dupliquer celui-ci.
NOTA: C'est un principe que j'utilise fréquemment, soit en shell (Linux) pour de l'administration soit en Java pour des applications clientes.

Si quelqu'un a un lien intéressant à fournir ou une amorce de solution, je suis preneur.

Merci
a+
franck

Salut.

Si j'ai bien compris le contexte, ton ruban est créé via un xml spécifique. Si oui, tu as déterminé un id pour les contrôles et un onAction qui contient le nom de la proc qui sera déclenchée lors du clic sur le bouton.

Cette procédure doit obligatoirement recevoir en paramètre le contrôle utilisé, ce qui permet le Select Case

Code:

---

1 2 3 4 5 6 7 8

Sub MaProc(Control As IribbonControl) Select Case Control.Id Case "Button1" ... Case "Button2" ... End Select End Sub

---

Salut Pierre,

Le ruban n'est pas créé via un xml spécifique.
Je parle de celui créé via l'Excel UI--> Fichier|Options|Personnaliser le ruban; j'ai créé un "Nouveau groupe" et j'y ai inséré des boutons ou actions (je ne sais pas quel est le bon terme !) lié(e)s à des "Sub".
Dans mon premier post j'ai mis en pièce jointe le bandeau.

Ta réponse m'as déjà éclairé sur une piste; je vais l'inspecter


Cordialement
Franck

NOTA: si je ne réponds pas de suite c'est que je fais ça en pointillé.

Ok.

Dans ce cas, ton ruban n'est pas créé par xml et ton bouton est donc lié directement à une macro. Deux cas se présentent alors:

• une macro n'est appelée que par un seul bouton, et tu n'as pas besoin de connaître son ID, tu sais que la macro a été actionnée par le bouton ¹;
• Une macro est appelée par plusieurs boutons, voir par du code externe au ruban. C'est alors pour moi un problème d'architecture ².

¹ Voici le schéma du cas 1

Pièce jointe 572520


² Je suppose que si tu as besoin de l'identifiant, c'est que tu es dans le cas n° 2. A ma connaissance, VBA n'expose pas nativement la possibilité de savoir quel bouton du ruban a appelé la macro

Pièce jointe 572527


Dans ce cas, je te propose l'architecture suivante

Pièce jointe 572523

Pour moi, une bonne architecture tient compte du fait qu'une procédure événementielle n'est jamais appelée que par un seul événement (dans ce cas, un bouton) et jamais par une autre procédure (voir ce billet et ce billet à ce sujet). On peut déroger à la règle dans le cas que je présentais dans ma première réponse, c'est-à-dire lorsque le ruban spécifique est créé par un xml personnalisé, car les procédures qui réagissent au clic doivent recevoir en paramètre un objet de type IRibbonControl qui offre notamment la propriété Id.

Il est également possible, en fonction du contexte, d'utiliser Application.Caller qui permet d'identifier l'appelant. Cela fonctionne par exemple pour un bouton placé sur une feuille, car dans ce cas Caller contient le nom du bouton. Mais cela ne fonctionne pas pour les boutons de ruban, car Caller renvoie dans ce cas un tableau inexploitable. Voir l'aide en ligne pour plus d'infos sur Application.Caller

Bonsoir,

En résumé ...

- La bonne pratique est de respecter le 1-1 --> événement-procédure (OK)
- Dans mon cas :
Un premier biais serait de passer par un xml personnalisé --> pour l'instant j'évite car pas expérimenté
Le deuxième serait d'utiliser les boutons et Application.Caller --> je veux éviter ce procédé (pas de boutons sur les feuilles)


Finalement, je vais garder le bandeau et en rester à mon code dupliqué; cela n'est pas capital.

Je te remercie pour le temps passé à étudier ce cas.
J'ai bookmarké tes billets intéressants.

Franck