[]Validate / CausesValidation => Ne pas utiliser
Bonjour,
bizarrement, c'est pas une question que je pose, mais j'apporte plutôt un élément de réponse à ceux qui se poseraient celle que je me suis posé ...
Je vais être plus clair !
J'ai un formulaire comportant des champs de type TextBox.
A chaque sortie, je veux valider la saisie afin de bloquer le passage au control suivant. Il me faut donc intervenir avant le passage de focus.
Je ne passe donc pas par les événements lostfocus/gotfocus.
En effet, comment empêcher le changement de focus si le test est effectué APRES le changement ?
Ne me répondez pas qu'il suffit de faire un setfocus dans le champ qui a reçu le focus, car si ce 2eme control possède également une méthode de control de saisie dans son événement lostfocus, on arrive sur des cas de boucles sans fin trés vite.
A moins d'imaginer un système de verrou, qui n'éxécute le test qu'à condition que le champ précédent a été validé ... mais c'ests trés lourd à gérer, et on se met à réinventer la poudre.
L'événement Validate semble en effet tout indiqué pour répondre à la problématique.
Je vous copie tels quels qques passages trés intéressants et explicites trouvés sur le net :
Citation:
Événement Validate des contrôles
Les contrôles génèrent aussi un événement Validate qui est déclenché avant que le contrôle ne perde le focus. Toutefois, cet événement survient uniquement lorsque la propriété CausesValidation du contrôle sur le point de recevoir le focus est à True. Dans de nombreux cas, l'événement Validate est plus approprié que l'événement LostFocus pour la validation des données parce qu'il survient avant la perte du focus. Pour plus d'informations, reportez-vous à la section « Validation de l'entrée d'un contrôle par restriction du focus » du chapitre 7, « Utilisation des contrôles standard de Visual Basic ».
Citation:
Validation des données de contrôle par restriction du focus
L'événement Validate et la propriété CausesValidation sont utilisés de paire pour vérifier l'entrée d'un contrôle avant d'autoriser l'utilisateur à le désactiver. Prenons, par exemple, une application contenant plusieurs zones de texte et un bouton Aide. Lorsque chaque zone de texte reçoit le focus, vous devez empêcher les utilisateurs de déplacer ce focus tant que les critères de validation spécifiques de la zone de texte ne sont pas remplis. Toutefois, vous devez également autoriser les utilisateurs à cliquer sur le bouton Aide à tout moment. Pour cela, vous devez affecter la valeur False au critère de validation de l'événement Validate ainsi qu'à la propriété CausesValidation du bouton Aide. Si la propriété a la valeur True (paramètre par défaut), l'événement Validate interviendra sur le premier contrôle. En revanche, si elle a la valeur False, l'événement Validate affecté au premier contrôle n'interviendra pas.
L'événement Validate est mieux adapté à la validation de saisie de données que l'événement LostFocus parce que, par définition, l'événement LostFocus intervient une fois le focus déplacé. En revanche, l'événement Validate vous permet d'empêcher le déplacement du focus vers un autre contrôle tant que toutes les conditions de validation ne sont pas remplies.
J'avais donc trouver une solution ... LA solution !
Mais mes jolis espoirs se sont vite envolé...
En effet, je me suis aperçu que dans certains cas, l'événement validate ne se déclenchait pas... J'ai d'abord pensé à une erreur de code de ma part, puis à une mauvaise initialisation des propriétés des controles de mon formulaire... Mais j'ai du me rendre à l'évidence : l'événement validate n'est pas fiable !
J'ai donc cherché à en savoir plus, et je suis tombé sur un article de microsoft édifiant, constatant effectivement et officiellement le bug.
A cette adresse http://support.microsoft.com/search/...og=LCID%3D1036 on apprend ceci :
Citation:
BUG: CausesValidation Property Does Not Trigger Validate Event
SYMPTOMS
The Validate event of a control is not executed when it loses focus to another control that has its CausesValidation property set to True.
STATUS
Microsoft has confirmed that this is a bug in the Microsoft products that are listed at the beginning of this article.
MORE INFORMATION
Microsoft Visual Basic 6.0 introduced a new Boolean property called CausesValidation on various controls, such as the TextBox. According to Visual Basic Help, when there is an attempt to put focus on a control that has its CausesValidation property set to True, the Validate event of the control that is losing focus executes. During that Validate event, you can verify that the data entered is valid and you can prevent the shift of focus to the new control if you want.
On y trouve d'ailleurs un exemple permettant de reproduire le bug !
Citation:
1. Create a new Standard EXE project. Form1 is created by default.
2. Add three TextBox controls to Form1.
3. Set the CausesValidation property in Text1 and Text3 to True.
4. Set the CausesValidation property in Text2 to False.
5. Paste the following code into Form1:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
|
Private Sub Text1_Validate(Cancel As Boolean)
Debug.Print "Text1's Validate Event"
End Sub
Private Sub Text2_Validate(Cancel As Boolean)
Debug.Print "Text2's Validate Event"
End Sub
Private Sub Text3_Validate(Cancel As Boolean)
Debug.Print "Text3's Validate Event"
End Sub |
Citation:
Run the sample project.
7. The focus begins on Text1. Click Text3. The CausesValidation property of Text3, set to True, causes the Validate event of Text1 to be executed as expected.
8. With the focus on Text3, click Text2. The CausesValidation property of Text2, set to False, does not cause the Validate event of Text3 as expected.
9. With the focus on Text2, click Text3. The CausesValidation property of Text3, set to True, does not cause the Validate event of Text2 as it should.
With the CausesValidation property of Text2 set to False, there does not appear to be any way to get a Validate event for Text2 to execute.
Aside from attempting to use the LostFocus event to manually call a Validate event for Text2 from Text2, you can work around this problem by changing the CausesValidation property from False to True.
Nous y sommes chers amis ! La validation des données ne passera pas par le CausesValidation ...
