Discussion :

[Tofalu]

Code :

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

1
2
3
4
5
Private Sub TextBox1_Change()
  Static javais As String
  If TextBox1.Enabled Then javais = TextBox1.Text: Exit Sub
  TextBox1.Text = javais
End Sub

Pourquoi mettre le if sur une ligne avec un :ExitSub ?

En VBA, il existe la structure If Then Else...
C'est en codant comme des cochons que l'on donne raison aux détracteurs du Visual Basic Et puis tant qu'on y est, respectons les conventions de nommage des objets et des variables

Enfin et surtout (mais je vous laisse faire) j'aurais pu créer une fonction paramétrable avec, pour paramètres : le contrôle, la propriété à inhiber, etc...

Si je ne me trompe pas la propriété à inhiber sera toujours text puisque c'est la seule qui lève l'évènement Change. Mais je suppose que tu parlais plutôt de la propriété "inhibante", enfin celle utilisée dans la comparaison

[ucfoutu]

Pourquoi mettre le if sur une ligne avec un :ExitSub ?

Ben...

pour coder comme un cochon, pardi ...

Plus sérieusement : car j'ai à quitter immédiatement, sans passer par une clause Else, pardi.

C'est ainsi que JE code et que j'encourage à coder.

Quant au reste (l'évènement Change) ? J'en reste coi !!!!!!

[Pierre Fauconnier]

...

Plus sérieusement : car j'ai à quitter immédiatement, sans passer par une clause Else, pardi.

C'est ainsi que JE code et que j'encourage à coder.

Quant au reste (l'évènement Change) ? J'en reste coi !!!!!!

La clause ELSE est pourtant bien présente.

Code :

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

1
2
3
4
5
6
7
8
9
 
Private Sub TextBox1_Change()
  Static javais As String
  If TextBox1.Enabled Then
    javais = TextBox1.Text
    else
    TextBox1.Text = javais
  endif
End Sub

et permet de n'avoir qu'une seule sortie de procédure, ce qui est préférable à un exit sub en plus de la sortie normale. Le code est ainsi plus propre.

[Maxence HUBICHE]

Si je ne me trompe pas la propriété à inhiber sera toujours text puisque c'est la seule qui lève l'évènement Change. Mais je suppose que tu parlais plutôt de la propriété "inhibante", enfin celle utilisée dans la comparaison

Pas bien compris chef !
quand je fais

Code :

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

1
2
3
4
5
6
7
 
Private Sub TextBox1_Change()
    TextBox2.Value = TextBox1.Value
End Sub
Private Sub TextBox2_Change()
    TextBox2.BackColor = Rnd * 16777215
End Sub

Je ne touche pas à TEXT, mais à VALUE, et pourtant, l'évènement Change est déclenché !
Je pense que je n'ai pas saisi ce que tu voulais dire

[Singular]

Pierre Fauconnier a dit:
... Le code est ainsi plus propre.

... et presque aussi rapide de passer sur un Else que sur un Exit Sub. Un flip-flop de processeur en plus pour évaluer le Else, ça ne donne pas des minutes d'ouvrage en plus à l'utilisateur.

Moi, je suis très énormément beaucoup en faveur du code propre. Ça facilite la vie de tous ceux qui ont subséquemment affaire au code. Une instruction par ligne de code. Y a rien de plus clair lors d'un débogage.

Je n'ai rien contre le fait que tu arranges ton code comme ça, ucfoutu. Faut juste pas le recommander aux autres. Ça fait pas très sérieux, l'ami...

[Singular]

Text et Value sont identiques dans un TextBox, sauf que Text est un String et Value un Variant. Tout ce qui arrive à Text arrive à Value et l'inverse est aussi vrai.

[Tofalu]

Pas bien compris chef !
quand je fais

Code :

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

1
2
3
4
5
6
7
 
Private Sub TextBox1_Change()
    TextBox2.Value = TextBox1.Value
End Sub
Private Sub TextBox2_Change()
    TextBox2.BackColor = Rnd * 16777215
End Sub

Je ne touche pas à TEXT, mais à VALUE, et pourtant, l'évènement Change est déclenché !
Je pense que je n'ai pas saisi ce que tu voulais dire

Je me suis mal exprimé, mais singular m'a compris.

Ce que je voulais dire, c'est qu'à part le contenu de la textbox, je vois pas très bien ce que je peux inhiber d'autre

la propriété à inhiber

Je ne vois pas très bien comment je peux par code empécher la modification de la propriété ForeColor par exemple

[ucfoutu]

Bonjour,

Lecture tout simplement trop rapide....

1) L'évènement Change n'est pas subi que par des textboxes
2) lorsqu'il est subi, il concerne une seule propriété (et seule cette dernière est alors bien évidemment concernée), mais cette propriété n'est pas la même pour tous les contrôles pouvant subir l'évènement change (et j'ose à peine parler, en plus, d'activex)
D'où le paramétrage d'une fonction...

[Benevole V1]

Bonjour à tous,

Presque 10 ans, jour-pour-jour par rapport à l'ouverture de cette discussion (non encore fermée !) que je viens de découvrir, je voudrais vous soumettre une solution au problème posé que j'ai souvent appliquée depuis 3 ans, qui fonctionne très bien et qui me semble bien plus simple que toutes celles proposées.
Je suis un nouveau membre et encore loin de maitriser VBA comme la plupart d'entre vous. Si vous pouviez me faire savoir si ma solution tient la route, cela me ferait le plus grand plaisir !

Je résume le problème : éviter que l'action sur un contrôle d'un UserForm ne déclenche en cascade d'autres procédures évènementielles que celle qui lui est associée (lorsque ce contrôle modifie, même indirectement, les propriétés d'autres contrôles associés à des procédures du type "_Change").
Pour éviter cela, je défini une seule variable "Public" du type "Boolean" que je nomme "CE".

Voici, en quelques lignes, la structure de mes procédures:

Sub (NomProcédure)
If Ce = False then Ce = True else Exit Sub
... instructions
Ce = False
End Sub

Merci de vos réponses que j'attends avec impatience...

[Ben_L]

Bonjour à vous,

Plusieurs remarques suite à votre message :

• Il est généralement préférable de créer une nouvelle discussion (quitte à référencer la précédente par un lien) plutôt que de reprendre un fil créé il y a 10 ans.
• La proposition que vous faîtes est identique à celle de Singular dans le post #3 de ce fil.
• Il est préférable de ne pas modifier la variable booléenne dans la procédure événementielle. En effet, dans cette procédure, on sait pas pour quelle raison le code est exécuté (modification du contenu du contrôle par du code ou par l'utilisateur ?).
  La réinitialisation de la variable booléenne doit à mon sens intervenir dans la procédure appelante.
  Dans l'exemple que vous donnez, vous modifiez 2 fois la variable CE, ce qui n'apporte rien.

Cordialement

[Benevole V1]

Réponse à Ben_L

Désolé, mais je n’ai pas retenu la solution #3 car elle me semblait plus compliquée que la mienne.
Je la reprend ci-dessus, mais je remplace «MonObjet_ProcessusEnCours» par mon «Ce» qui me paraît plus simple à lire…

Je défini une variable globale dans la section Déclarations d’un module de code (Pas de l’UserForm car les procédures du code n’y ont pas accès)
Public Ce as Boolean

Avant d'affecter une nouvelle valeur au contrôle je mets dans la procédure appelante (PA) avant l’instruction qui va modifier le contrôle :
Ce = True

Ensuite, dans :
Private Sub MonObjet_Change()
If Ce = True Then Ce = False: Exit Sub (en une ligne, cela me semble plus clair)
...
End Sub

D’accord ça marche, mais on risque d’oublier le «Ce = True» lorsque l’on écrit le code dans la PA.
De plus chaque instruction (dans une ou plusieurs PA !) destinée à modifier l’une des propriétés de chaque contrôle devra être précédée de «Ce = True»
A cela, Il y a bien la solution consistant à placer «Ce = False» dans la PA avant son «End Sub» … et ne pas l’oublier.

Mais je reviens sur ma solution.
Je ne vois pas ce qui empêche d'activer ma variable "Ce" dans une procédure évènementielle (PE).
Car si mon code veut modifier un contrôle, c’est suite à une action sur un autre contrôle.
Si toutes mes PE associées à une contrôle commencent par la simple instruction …
If Ce = False Then Ce = True Else Exit Sub
… et se terminent par …
Ce = False
… je suis sûr que la première qui sera déclenchée bloquera toutes les suivantes.
Et cela en employant seulement 2 lignes d’instruction dans les seules PE qui risquent de créer l’effet «domino» que je veux éviter et sans encombrer les autres procédures, bien plus complexes, de mon code.

Ma solution permet aussi à 2 contrôles d’interférer l’un sur l’autre, par exemple :
> Sélection d’un modèle de voiture proposé en colonne 1 d’une ListBoxA
ListBoxA_Change propose dans une ListBoxB les couleurs disponibles pour ce modèle (ListBoxB_Change est bloqué par Ce = True)
> Sélection de la couleur dans la ListBoxB
ListBoxB_Change inscrit la couleur choisie dans la colonne 2 de la ListBoxA (ListBoxA_Change est bloqué par Ce = True)

Merci encore de m’avoir répondu si vite. Votre réponse m’a permis d’approfondir un problème essentiel pour mes développements mais je reste toujours ouvert à vos remarques et suggestions.

Je tiendrais compte de votre première remarque. Le problème est le site de «développez.net» est assez complexe et je ne sais pas si je saurais créer un lien avec une précédente discussion.