Discussion :

[J1]

Bonjour,

je recherche un événement VBA se déclenchant (dans un formulaire) avant le changement d'enregistrement, que celui-ci ait ou non été modifié.
J'ai eu beau passer tous les événements de formulaire en revue, je n'en ai trouvé aucun répondant précisément à mes besoins.

PS : l'objectif serait d'effectuer des contrôles sur l'enregistrement en cours avant de passer au suivant, rien de bien original donc

Merci d'avance pour vos lumières.

[Domi2]

Bonjour,

avant le changement d'enregistrement, que celui-ci ait ou non été modifié.

Un tel événement n'existe pas.

Ce qui m'intrigue, c'est pourquoi veux-tu contrôler tes enregistrements si ceux-ci n'ont pas été modifié ?

Un contrôle lors de l'insertion de l'enregistrement ne serait pas suffisant ?

Domi2

[J1]

Tout d'abord, merci pour ta réponse, Domi2.

En fait, l'idée est que l'utilisateur doit pouvoir accéder à des données brutes, afin de pouvoir lui-même les corriger si nécessaire. Néanmoins, si au terme de ses éventuelles corrections, des erreurs bloquantes pour la suite du traitement subsistent, il faut l'empêcher de passer à l'enregistrement suivant.

L'idéal serait que je parvienne à ce résultat via un événement de niveau formulaire plutôt que de devoir ajouter des boutons personnalisés qui gèreraient le déplacement entre enregistrements.

[Domi2]

Re,

Ok ! Donc, si l'utilisateur ne fait pas de modification, c'est que les données contenues dans l'enregistrement sont correctes si elles ont été contrôlées lors de l'insertion.

Tu peux donc utiliser l'événement AVANT Maj du formulaire.

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
28
29
30
31
32
33
Private Sub Form_BeforeUpdate(Cancel As Integer)
 
    'On Error Goto GestionErreurs
 
    'Tests de plausibilité
    If Not IsDate(Me.txtClientDateAdhesion) Then
 
        MsgBox "La date d'adhésion doit obligatoirement être saisie !", vbInformation + vbOKOnly, CurrentDb.Properties("AppTitle")
 
        Me.txtClientDateAdhesion.SetFocus
 
        Cancel = True
 
        Exit Sub
 
    End If
 
    'Test suivant
    If IsNull(Me.txtClientNom) Then
 
        MsgBox "le nom doit obligatoirement être saisi !", vbInformation + vbOKOnly, CurrentDb.Properties("AppTitle")
 
        Me.txtClientNom.SetFocus
 
        Cancel = True
 
        Exit Sub
 
    End If
 
    'Etc...
 
End Sub

Tant qu'une donnée est erronée, l'événement est annulé.

Domi2

[J1]

Re,
Ok ! Donc, si l'utilisateur ne fait pas de modification, c'est que les données contenues dans l'enregistrement sont correctes si elles ont été contrôlées lors de l'insertion.

En fait, ce que j'essayais d'expliquer dans mon message précédent, c'est que les données insérées en table étaient brutes (donc potentiellement erronées) et qu'avant tout contrôle automatisé, on laissait l'utilisateur procéder à ses propres corrections éventuelles.

[Domi2]

Re,

c'est que les données insérées en table étaient brutes (donc potentiellement erronées) et qu'avant tout contrôle automatisé, on laissait l'utilisateur procéder à ses propres corrections éventuelles.

D'accord...

Pas testé, je n'ai pas Access sous la main...

Tu mets en place ton contrôle de plausibilité comme indiqué précédemment (ou une simple MsgBox "Coucou" pour vérifier que tu passes bien dans l'événement AVANT Maj).

Sur l'événement Sur Activation du formulaire (qui se produit à l'ouverture du formulaire et à chaque changement d'enregistrement), tu ajoutes cette ligne de code :

Code :

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

Me.Dirty = True

Même si l'utilisateur ne fait rien, l'enregistrement devrait être considéré comme "modifié".

Domi2

[J1]

Ingénieuse idée, que je viens donc de tester !
Malheureusement, deux inconvénients apparaissent :

- mon formulaire principal contient un sous-formulaire. Hors, l'événement BeforeUpdate du formulaire principal se déclenche notamment lors du passage dans le sous-formulaire. Concrètement donc, lorsque je tente de passer dans le sous-formulaire, le test bloquant que j'ai mis en place est activé, m'indiquant qu'une information est mal renseignée, ce qui m'empêche donc de passer dans le sous-formulaire. Hors, les informations à corriger peuvent justement se situer dans ce sous-formulaire.

- en outre, pour passer outre (l'astucieux) Me.Dirty=True, l'utilisateur peut presser la touche Echap. L'enregistrement ne sera donc plus considéré comme modifié et l'événement BeforeUpdate ne sera donc pas déclenché.

Dommage, car cette idée me plaisait bien !

[Domi2]

Re,

La touche Escape, tu peux la désactiver !

Pour l'autre problème, j'ai de la peine à me faire une idée...

Cela devrait peut-être pouvoir être contourné en testant le contrôle qui reçoit le focus. Si c'est le sous-formulaire, alors on annule le test... A essayer...

Domi2