Discussion :

[OrDonc]

re
@ Teddy*, excuse-moi de polluer ton fil mais étant interpellé …

...
@ordonc: je comprends ton point de vue avec le controltiptext sauf qu'il est un peu long a la detente en pratique il n'apparait pas tout de suite ,meme un msgbox dans l'evenement est plus rapide

@ Patrick*, par définition, cette propriété gère cet évènement avec la souris. Peux-tu, s'il te plait, me donner un exemple avec un "MsgBox" sans programmation compliquée ?
Tu peux utiliser mon fichier de travail**.

@Pierre*, je respecte tes avis tout en n'étant pas toujours convaincu (loin de là par certains).
Si tu veux en discuter en toute cordialité, ma messagerie personnelle est ouverte pour cela. On pourra argumenter à souhait.

* dans ma logique de noms bien nommés, j'y inclus leur simplification d'écriture (à chacun de reconnaître les siens).

** j'ai vu qu'il était malvenu (?) de joindre un fichier cependant je pense que c'est une bonne base de départ, de discussion surtout pour nous éviter de construire un modèle de test (qui pourrait ne pas correspondre au contexte préparé).

Bonne journée à tous

[Pierre Fauconnier]

Ordonc,

C'est "malvenu" à l'entame d'une discussion, mais à ce point d'une discussion, c'est très bienvenu. Par principe, je ne discute jamais de cela en mp, le débat étant à mon avis utile à tous s'il est cordial (et ZTeddy nous pardonnera, je pense, de "polluer" son fil)

[Pierre Fauconnier]

Je vais illustrer mon propos de la "responsabilité" de la classe par un exemple, qui va mettre en évidence que la classe est effectivement générique, c'est-à-dire qu'on n'a rien à modifier à l'intérieur de son code tout en lui permettant de "jouer" avec différents userforms au sein d'un même projet (ou pas ^^) et de rediriger le code en fonction du userform qui est appelé (ou plutôt de ce qu'elle doit faire par rapport au userform dont elle gère les objets).

Voici le code générique de la classe. On remarque qu'elle reçoit en propriété publique autoimplémentée une variable EventClick qui va contenir le nom de la procédure extérieure à la classe qui sera appelée lors du clic. C'est donc au moment du click générique que le code est redirigé.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
Option Explicit
 
Public WithEvents chk As MSForms.CheckBox
 
Private Items As New Collection
Private mCheckBoxManager As checkBoxManager
Public EventClick As String
 
Sub Init(usf As MSForms.UserForm, EventClick As String)
  Dim ctrl As MSForms.Control
 
  Me.EventClick = EventClick
  For Each ctrl In usf.Controls
    If TypeName(ctrl) = "CheckBox" Then
      Set mCheckBoxManager = New checkBoxManager
      With mCheckBoxManager
        Set .chk = ctrl
        .EventClick = EventClick
      End With
      Items.Add mCheckBoxManager
    End If
  Next
End Sub
 
Private Sub chk_Click()
  If EventClick <> "" Then Run EventClick, chk
End Sub

Le code de n'importe quel userform dont on souhaite gérer les click sur checkbox de manière générique sera le suivant, et l'on voit bien qu'il est minimaliste. La seule chose qui change entre les userforms est le second argument de l'Init de l'objet de la classe (Pour le userform1, c'est Usf1_CheckBox_Click, pour le userform2, c'est ClickOnUsf2CheckBoxes).

Voici l'initialisation du userform1

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
Option Explicit
 
Dim mCheckBoxManager As New checkBoxManager
 
Private Sub UserForm_Initialize()
  mCheckBoxManager.Init Me, "Usf1_CheckBox_Click"
End Sub

Voici le code du userform2 (à part le second argument de l'init, c'est identiquement le même que celui du userform1).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Dim mCheckBoxManager As New checkBoxManager
 
Private Sub UserForm_Initialize()
  mCheckBoxManager.Init Me, "ClickOnUsf2CheckBoxes"
End Sub

Dans un module standard, on crée les procédures Usf1_CheckBox_Click et ClickOnUsf2CheckBoxes qui doivent avoir une signature particulière, à savoir revevoir le contrôle qui a été cliqué.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
Sub Usf1_CheckBox_Click(chk As MSForms.CheckBox)
  UserForm1.Width = UserForm1.Width + 10
End Sub
 
Sub ClickOnUsf2CheckBoxes(chk As MSForms.CheckBox)
  UserForm2.Caption = chk.Name
End Sub

En ouvrant l'un ou l'autre des userforms, on voit bien que la classe fait son job et rien que son job, en redirigeant les clics vers la procédure souhaitée du module standard.

Imaginons qu'un Userform3 doit réaliser pile poil la même chose que le userform1, il suffit, à l'initialisation du userform3, d'utiliser comme second argument la valeur Usf1_CheckBox_Click. La classe est alors parfaitement générique et joue son rôle, mais uniquement son rôle. La classe constitue donc bien une couche d'abstraction, une brique logicielle qui vient s'insérer là où on a besoin d'elle . Elle agit comme une boite noire dont le client ignore tout du fonctionnement mais sait comment l'utiliser, sans avoir besoin d'en modifier le code.


PS: Les noms des procédures appelées pour les userform1 et userform2 sont volontairement fort différents pour éviter que l'on me dise "il suffit de les reconstituer en fonction du nom du formulaire passé", car cela impose aux formulaires d'avoir un nom que la classe pourra gérer, ce qui contraint le code client de la classe à s'adapter à celle-ci, ce qui va à l'encontre du but poursuivi, selon moi. Et bien entendu, si cette classe acquérait la responsabilité de gérer aussi le Change ou un autre évènement des checkbox, il faudrait ajouter le code générique au sein de la classe, ainsi que les propriétés publiques autoimplémentées qui vont avec.

[patricktoulon]

re
oui j'ai compris ton point de vue Pierre en ce qui concerne l'evenement lui meme il n'a besoins de rien d'autre
je suis d'accords le listener en lui meme ne necessite rien une fois tout les checkboxs agrangé

mais si il doit faire quelque chose dans le userform en fonction de cet evenement checkbox (quoi que se soit )que fait il ? il exteriorise ce quelque chose
je suppose que c'est cela que tu veux me dire

[Pierre Fauconnier]

[...]
mais si il doit faire quelque chose dans le userform en fonction de cet evenement checkbox (quoi que se soit )que fait il ? il exteriorise ce quelque chose
je suppose que c'est cela que tu veux me dire

Je pense que ton post a croisé le mien, qui illustre effectivement que ce qui doit être fait sur le clic est hors de la classe, mais appelé par celle-ci. On voit ici une utilisation intéressante de Run

[patricktoulon]

re
oui aussi par exemple l'evenement a exteriorisé dans le usf en public
et dans l'evenement dans la classe un run usf.nom_de_la_fonction (voir meme avec argument(s))
ca m'est arrivé dans certains de mes developpement de faire comme ca pour ne pas tout réécrire ,plus je vieilli plus je deviens fainéant
avoir aussi si pour rendre pour le coup absolument generique la chose injecter dans la classe le nom de la sub a appeler dans l'evenement classe
pour le coup la oui cela serait absolument generique peut etre callbyname j'ai pas encore exploré

[Pierre Fauconnier]

[...]
et dans l'evenement dans la classe un run usf.nom_de_la_fonction (voir meme avec argument(s)) [...]

Non!! Pas usf.Nom_De_La_Fonction. La fonction appelée par Run doit être extérieure au userform. Si tu la mets à l'intérieur du userform, tu imposes à ton userform une architecture particulière, et tu crées donc un couplage fort entre le userform et la classe. C'est contre-productif. La procédure appéle par le Run est hors de la classe, mais aussi hors du userform. La seule chose que doit respecter ton userform, c'est d'initialiser la classe avec le nom de la procédure standard (éventuellement paramétrée comme dans mon exemple). De cette façon, tu minimises le couplage et ta classe est vraiment générique.

De toute façon, Run ne permet pas d'appeler usf.Fonction. La fonction/procédure appelée par Run doit obligatoirement être dans un module standard car Run ne peut appeler que des fonctions/procédures de module standard

[...]avoir aussi si pour rendre pour le coup absolument generique la chose injecter dans la classe le nom de la sub a appeler dans l'evenement classe
pour le coup la oui cela serait absolument generique peut etre callbyname j'ai pas encore exploré

Prends le temps de regarder et d'analyser mon code, car il est totalement générique au niveau de la classe. C'est exactement ce que je fais (injecter le nom de la proc via la propriété EventClick) dans le code que je donne à 14:39

[patricktoulon]

re
ok vu ton precedent message on se croise a chaque fois


je ne sais pas si c'est possible d'injecter le nom d'une public sub d'un userform ca serait absoloment genial!!! pour la transportabilité (usfavec la classe)
je vais tripatouiller la dedans

[Pierre Fauconnier]

[...]je ne sais pas si c'est possible d'injecter le nom d'une public sub d'un userform[...]

Comme je l'ai dit, ce n'est pas possible. En VBA, Run impose que la proc/fonction appelée soit dans un module standard. Donc, comme je l'ai montré, Run "usf.Nom_De_La_Fonction" n'est pas permis. Si c'est une fonction qui est appelée et que l'on veut en récupérer la valeur à la suite du Run, on peut, car Run est une instruction/fonction. je l'ai ici utilisée comme une instruction, mais on peut l'utiliser comme ceci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Mavariable = run(NomFonction, Paramètres...)

[...]ca serait absoloment genial!!! pour la transportabilité (usfavec la classe)

Je ne crois pas du tout que ce serait génial, pour les raisons que j'ai expliquées plus haut dans la discussion, à savoir que cela imposerait au userform d'utiliser une architecture dont la classe aurait besoin (couplage fort entre le usf et la classe), alors qu'en redirigeant vers une proc standard, le couplage entre usf et classe est minimal. Crois-moi, l'architecture que je présente ici est la plus générique tout en étant celle qui offre la souplesse maximale

Je conclurai en disant que, dans les faits, avoir besoin d'une classe générique pour gérer tous les évènements de tous les checkbox de tous les formulaires d'un projet est juste une vue de l'esprit. Donc, génériser une classe dans des limites raisonnables pour des besoins récurrents est une bonne chose, mais il ne sert à rien d'inventer le supertruc hyupergénérique qui, de par son degré d'abstraction élevé, devient difficile et/ou lourd à manipuler. Ce que j'expose ici est à mon avis le maximum d'une générisation "raisonnable" d'un outil.

[patricktoulon]

re
ok pour run ca je savais qu'il fallait absolument qu'elle soit dans un module standard
je regarde en ce moment avec callbyname pour le sport
si le demandeur ne sais pas faire une classe control apres ca j'abandonne moi

[Pierre Fauconnier]

Ca fonctionne avec CallByName, tu peux appeler une procédure du userform. Et finalement, pourquoi pas? Ca encapsule la procédure dans le userform. Mais ça induit que le traitement soit spécifique à chaque userform. Si plusieurs userforms doivent pointer vers la même proc, tu ne pourras pas le faire ainsi. Je préfère donc la procédure avec RUN qui me semble plus générique (c'est juste mon avis, ce n'est pas LA vérité )...

Ceci dit, je pense que nous sommes d'accord que c'est pour le fun. Dans les faits, il me semble que l'on poussera rarement si loin en VBA, quoique . Il me semble en tout cas qu'on a fait un tour assez complet du problème et des possibilités

[OrDonc]

Re

...
Ceci dit, je pense que nous sommes d'accord que c'est pour le fun. Dans les faits, il me semble que l'on poussera rarement si loin en VBA, quoique . Il me semble en tout cas qu'on a fait un tour assez complet du problème et des possibilités

D'accord pour le Run et le Fun mais qu'en est-il du chemin externe à emprunter quand chaque cas réclame une, voire 2, macros totalement indépendantes les unes des autres ?
Les 8 macros étant écrites dans le module ouvert, fais-je une bêtise avec cet exemple ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Sub Usf1_CheckBox_Click(chk As MSForms.CheckBox)
  Select Case Val(Right(chk.Name, 1))
    Case 1: If chk Then macro1a Else macro1b
    Case 2: If chk Then macro2a Else macro2b
    Case 3: If chk Then macro3a Else macro3b
    Case 4: If chk Then macro4a Else macro4b
  End Select
End Sub

Si oui comment dois-je corriger ?
Si non, à quoi sert le Module de classe (même avec 36 formulaies) ?
Dans ce cas (et oui toujours le contexte), je proposerais dans la fenêtre de code du formulaire contenant les 8 macros appelées (pour éviter les dispersions dans plusieurs fenêtres de codes donc suivre le déroulemnt plus facilement) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
Private Sub C1_Click()
  If C1 Then macro1a Else macro1b
End Sub
Private Sub C2_Click()
  If C2 Then macro2a Else macro2b
End Sub
Private Sub C3_Click()
  If C3 Then macro3a Else macro3b
End Sub
Private Sub C4_Click()
  If C4 Then macro4a Else macro4b
End Sub

Nota : cela ne me prend pas plus de temps de changer le nom que de l'écrire dans les macros (même avec le Me.) surtout qu'on doit changer aussi la propriété "Caption" dans la Fenêtre des propriétés pour connaître le cas étudié.

[patricktoulon]

oui pierre c'est pour le fun et le sport
j'ai pas trouvé avec callbyname je prends si tu a un exemple

et oui ca induit que dans la classification on injecte l'usf et la public sub de l'usf , c'est interessant dans le cadre de la transportabilité

[Pierre Fauconnier]

Salut OrDonc,

Une classe comme celle que j'ai montrée n'est utile que dans deux cas:

1. la création dynamique de contrôles nécessitant une gestion des évènements;
2. la simplification du code lorsque les checkbox doivent réagir de la même façon.

Dans le cas que tu illustres avec les Select Case, soit on est dans le cas 1, soit c'est inutile et il est plus simple de gérer les évènements pour chaque checkbox. Dans 99% des cas d'utilisation de checkbox dans un userform, il n'est donc pas utile de passer par la classe perso

[patricktoulon]

ordonc tu t'es perdu dans ton truc on comprends mieux ta question "a quoi ca sert...."
tu a tendance a oublier qu'une sub ou fonction peut avoir des arguments
appele en qu'une avec les argument qu'il faut

[Pierre Fauconnier]

[...]
j'ai pas trouvé avec callbyname je prends si tu a un exemple[...]

Avec la procédure publique suivante dans Userform1, tu peux utiliser callbyname userform1,"test",VbMethod, éventuellement avec des arguments.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Public Sub Test()
  MsgBox "Test"
End Sub

Mais apparemment, ça ne fonctionne pas avec un objet variabilisé... (mais je n'ai jamais vraiment utilisé cette instruction, donc je ne la maîtrise pas)

[patricktoulon]

j'avais fai comme ca aussi dans mes test et ca ne fonctionne pas je vais chercher
merci pour l'exemple

[Pierre Fauconnier]

La première ligne passe, pas la seconde... Du coup, l'intérêt est limité à des procédures qui changent lors de l'appel, mais ne peut pas être utilisé pour des objets qui changent lors de l'appel.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Sub Test()
  Dim usf As UserForm1
 
  CallByName UserForm1, "test", VbMethod
  CallByName usf, "test", VbMethod
End Sub

[OrDonc]

Suite et fin (pour moi)

@Pierre : une ligne directrice de mes interventions est de me placer toujours dans un cadre précis pour choisir les outils les plus pertinents. Je suis désolé de n'avoir pas su le faire apparaître clairement.

ordonc tu t'es perdu dans ton truc on comprends mieux ta question "a quoi ca sert...."
tu a tendance a oublier qu'une sub ou fonction peut avoir des arguments
appele en qu'une avec les argument qu'il faut

Patrick, je ne vois pas quels sont les éléments de mes réponses te font penser à cela.
Encore une fois, donne- moi un exemple précis (dans le contexte que j'ai évoqué) d'une "sub" ou d'une "fonction" à utiliser.

[Pierre Fauconnier]

Ordonc,


C'est bien ainsi que je voyais tes interventions, et c'est d'ailleurs ce qui guide les miennes, ainsi que mes choix de code et d'architecture 😉