Collection module classe 2024 patricktoulon (classe controls) gérer Enter/exit TextBox 1.0 1.0

patricktoulon

XLDnaute Barbatruc

• 30 Septembre 2024

• #61

re
Bonjour @Dudu2
on s’aperçoit très vite des limites de cette pratique
par exemple en l'utilisant sur 2 userform en même temps
sachant que la variable classe de l'userform(la mère) est utilisée dans le module classe
sur deux userforms ça devient le bordel le pauvre module classe tourne en bourrique
car le nom est le même dans la classe et le userform

Spoiler: à méditer

ne vaut il pas tuer les child et être tranquille sur 1 ,2 ou plus userforms
ou
carrément utiliser des variables publiques dans les userforms respectifs

je me souvient pourquoi je n'utilisait pas ce procédé
c'est en refaisant mes classes demo comme ca que je m'en suis souvenu

 

Dudu2

XLDnaute Barbatruc

• 30 Septembre 2024

• #62

Bonjour @patricktoulon,
Même si le nom de la Classe est le même dans les 2 UserForms, souviens-toi que ce nom est qualifié par le UserForm concerné. Donc il ne peut pas y avoir de confusion à ce niveau. Ni au niveau des Controls.
UserForm1.Classe est bien différent de UserForm2.Classe.

je me souvient pourquoi je n'utilisait pas ce procédé

Cliquez pour agrandir...

Tu n'as jamais envisagé d'utiliser ce procédé puisqu'il est issu de notre discussion récente.

Edit:
La Classe ne sert qu'à générer des instances et les instances relatives à 2 UserForms sont parfaitement distinctes, le lien Mère -> Filles par la Collection est établi dans l'instance du UserForm concerné et pas dans un espace commun. Le UserForm concerné qualifie toujours l'accès à son instance mère dans le code de la Classe.

 

Dernière édition: 30 Septembre 2024

patricktoulon

XLDnaute Barbatruc

• 30 Septembre 2024

• #63

si avant j'utilisais du public dans le userform
d'ailleurs je l'utilise dans ma classe xml comme j'ai besoin de qu'une mère pour créer un pseudo domdoc

je te l'accorde en théorie même "avec le même Nom un object a sa propre address
sauf que en pratique par exemple sur mon mouseover on voit de temps en temps
une confusion et un bouton se colorer dans l'autre userform
"a fin de ne p"as pourrir cette ressource je vais ouvrir un post sur le forum

 

patricktoulon

XLDnaute Barbatruc

• 30 Septembre 2024

• #64

@Dudu2
A ben pour le coup j'ai trouvé un phénomène intéressant
la confusion ne se fait plus quand les instances mère sont lancée dans la classe userform et non l'object

 

Dudu2

XLDnaute Barbatruc

• 30 Septembre 2024

• #65

Ok. Qu'est-ce que tu appelles l'object ?

 

patricktoulon

XLDnaute Barbatruc

• 30 Septembre 2024

• #66

re

VB:

Private Sub UserForm_Activate()
'ici on est dans l'object userform "avec tout ses controls et tout le toutim
End Sub

Private Sub UserForm_Initialize()
'ici on est dans la classe module userform
End Sub

d'ailleurs tu le sais bien que la moindre allusion à l'userform dans n'importe quel module déclenche l'event initialise mais pas ce qui est dans l'activate

 

Dernière édition: 30 Septembre 2024

patricktoulon

XLDnaute Barbatruc

• 1 Octobre 2024

• #67

Bonjour @Dudu2
j'ai retrouvé des exemples de classe mouse over que je faisait sur DVP(15 ans déjà)
et là j'ai eu des sueur froides
il est même inutile de variabliser le userform dans la classe dans le cas ou le controls est enfant direct du userform
il suffit de mettre dans l'event par exemple ou mon event est "BT"
bt.parent.clas.OldControl

 

patricktoulon

XLDnaute Barbatruc

• 1 Octobre 2024

• #68

@Dudu2 j'ai compris pourquoi il est ESSENTIEL!!!! d'instancier dans le initalise

par ce que dans le activate quand tu passe d'un userform à l'autre tu ré instancie des classes et elle n'ont plus la même address(objPtr) même si elle sont fonctionnelles les précédentes se mélangent en contrôlant les address des object classe on s'en rend compte

 

Dudu2

XLDnaute Barbatruc

• 1 Octobre 2024

• #69

Bonjour @patricktoulon,

Tu as parfaitement raison car lorsqu'on revient d'un UserForm dans un UserForm, l'Activate se ré-exécute.
C'est pour ça que je code toujours les Activate de cette manière.

VB:

'-----------------
'UserForm Activate
'-----------------
Private Sub UserForm_Activate()
    'Flag de 1ère activation pour éviter de traiter les Activate de retour de UserForms de 2ème niveau
    Static UserFormInitialised As Boolean

    'Initialisation UserForm
    If Not UserFormInitialised Then
        UserFormInitialised = True
        Call UserForm_Initialisation
    End If
End Sub

Mais par prudence, pour ceux qui ne sont pas conscient de ce phénomène (presque tout le monde en fait), il vaut mieux utiliser le UserForm_Initialize(), c'est exact.

 

Dudu2

XLDnaute Barbatruc

• 1 Octobre 2024

• #70

C'est pour ça que je code toujours les Activate de cette manière.

Cliquez pour agrandir...

Comme tu t'en souviens, on avait montré que le UserForm_Initialize() se déclenche trop facilement, à la simple référence à une propriété du UserForm.

C'est pour ça que je n'aime pas placer des traitements plus ou moins lourds dans le UserForm_Initialize() qui n'est peut-être jamais suivi d'un UserForm.Show et préfère le UserForm_Activate() qui correspond vraiment à son activation / affichage. Mais il faut faire attention à ce phénomène de retour d'un UserForm de 2ème niveau et utiliser un flag pour que le UserForm_Activate() ne s'exécute qu'une seule fois pour ce qui concerne spécifiquement les traitements d'initialisation.

 

patricktoulon

XLDnaute Barbatruc

• 1 Octobre 2024

• #71

re
oui le flag est une idée aussi
ce qui étonnant c'est que l'objPtr retourne bien une addresse distincte et différente pour chaque instance ,donc théoriquement il ne devrait pas se produire ce phénomène

ce que je constate aussi
c'est que quand le lance deux classe mère de deux userform différents
a la fermeture de ceux ci, excel tourne en boucle et je suis obligé de terminer le procc dans les taches

avec ma technique de la référence circulaire(la mère membre des child) je n'ai pas tout ces soucis

c'est donc pour moi au besoins qu'il faut choisir la méthode
difficile dans ce cas de faire du générique dans le cadre ou une classe mère va engendrer des classe child
tiens voila la classe mouver or switchColor for commandButton

1. dans la console tu a d'inscrit les ouverture et fermeture
2. quand j'ouvre un userform ca va (l'un ou l'autre)
3. quand j'ouvre les deux userforms il fonctionne correctement que quand la mère est instancié dans le initialise
4. quand je ferme les userforms les classe sont bien détruites mais je ne peux plus fermer excel ou quoi que se soit dans mon bureau obligé de tuer la tache excel

 

Pièces jointes

• Class CommandButton v4 by patricktoulon (1).xlsm

  30.5 KB · Affichages: 0

Dudu2

XLDnaute Barbatruc

• 1 Octobre 2024

• #72

Je n'ai pas les comportements que tu décris.
Avec le code de ma ressource qui utilise la technique dont on parle, dans le fichier ci-dessous, j'ai ajouté un 2ème UserForm selon le même principe que dans le 1er UserForm.
Tout se déroule normalement. Regarde les traces.

 

Pièces jointes

• Class for UserForm Control Enter and Exit Events - 2 UserForms.xlsm

  93.1 KB · Affichages: 1

patricktoulon

XLDnaute Barbatruc

• 1 Octobre 2024

• #73

re
a ben bien sur il sont modal
des que je suis sur le 2 je ne peux plus revenir sur le 1
du peux donc pas tester mes dires

 

patricktoulon

XLDnaute Barbatruc

• 1 Octobre 2024

• #74

re
la preuve en video que chez toi l'erreur y est aussi

 

Dudu2

XLDnaute Barbatruc

• 1 Octobre 2024

• #75

a ben bien sur il sont modal
des que je suis sur le 2 je ne peux plus revenir sur le 1
du peux donc pas tester mes dires

Cliquez pour agrandir...

Ils sont maintenant tous les 2 vbModeless, tu peux tester tes dires et constater que ça fonctionne sans problème.

Je ne sais pas comment tu as codé, mais si ce principe ne convient pas à ton code, tu peux revenir sur l'instance mère dans les child.