Discussion :

[mouett]

Bonjour,

Je connais certains aspects d'access, notamment le requêteur et les tables, mais très peu les formulaires. Je souhaite faire un petit développement pour aider un ami, et je voudrais démarrer le mieux possible (en ce moment, je tourne en rond).
Il y a pas mal de tables dans cette application, et notamment des tables de typologie qui sont très petites en nombre d'enregistrements et en nombre de colonnes.
Je voudrais pouvoir les afficher/créer/mettre à jour à partir d'un écran très simple qui affiche la table en entier et sans utiliser des boutons de commande, ce qui me semblerait très lourdingue !!!.
Le look qui conviendrait bien est la feuille de donnée. J'ai vu qu'on peut afficher un formulaire en mode feuille de donnée, mais je ne vois pas comment intercepter les événements et les traiter. Par exemple, si l'utilisateur essaie de créer un doublon (il y a une clé primaire), le message envoyé par access est incompréhensible pour l'utilisateur. Je voudrais le modifier.
Je suis un peu familiarisée avec les procédures evenementielles de VBA et la gestion des erreurs. J'arriverais à m'en sortir je pense, si quelqu'un peut me dire où placer cette procédure (quel objet et quel événement)
Merci d'avance pour votre aide

[LedZeppII]

Bonjour et bienvenue sur le forum,

Les formulaires ont un événement "Sur erreur" que l'on peut gérer avec une procédure événementielle.

Voici un exemple

Code vba :

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
Option Compare Database
Option Explicit
 
#Const DBG = 0
 
Private Sub Form_Error(DataErr As Integer, Response As Integer)
#If DBG = 1 Then
    MsgBox "Erreur N° " & DataErr
#End If
Select Case DataErr
    ' doublons dans champs index, clé principale ou relation interdisant les doublons
    Case 3022
        MsgBox "Il y a un doublon sur " & Me.TelNum
        Me.TelNum.SetFocus
        ' Ignorer l'erreur
        Response = acDataErrContinue
    ' Autre cas
    Case Else
        ' Traitement par défaut de l'erreur par Access
        Response = acDataErrDisplay
End Select
End Sub

Dans cet exemple mon formulaire est basé sur une table ayant une clé sur NumTel.
S'il y a une erreur 3022 (doublon) ce sera forcément sur ce champ car c'est le seul ayant un index dans ma table.

#Const et #If ... #End If me sert au débogage pour afficher le code de l'erreur dans une MsgBox,
et éventuellement ajouter par la suite un Case dans mon code pour gérer cette erreur.

A+

[mouett]

Merci de ta réponse et de ta "bienvenue", c'est agréable d'être bien accueilli

J'ai réussi à installer le code, et ça marche très bien. Il est au niveau du formulaire et pas au niveau de la zone de saisie, c'était ma question "métaphysique", et tu m'as très bien répondu !!

Par contre, je ne comprends pas tout, et je vais devoir approfondir VBA, mais tu auras peut-être des réponses rapides sur quelques unes de mes interrogations:

1) Comment Access sait-il qu'il doit appeler cette procédure en cas d'erreur (il pourrait y en avoir plusieurs au niveau formulaire). Est-ce que c'est par le nom Form_Error ?

2) En faisant F1, je ne trouve pas acDataErrContinue et acDataErrDisplay (j'utilise Access 2003)

3) Concernant le fonctionnement de la procédure, je crois comprendre qu'elle reçoit le code erreur dans "DataErr" le 1er argument quand elle est appelée par Access, puis elle met la valeur qui va bien dans "réponse" son deuxième argument. Mais après qu'est-ce qui se passe ? Je suppose qu'Access agit différement suivant la réponse, mais que fait-il ?

4) Quel est l'usage des "#" devant #Const et #If ?

A bientôt

[LedZeppII]

Bonjour,

1. Comment Access sait-il qu'il doit appeler cette procédure en cas d'erreur (il pourrait y en avoir plusieurs au niveau formulaire). Est-ce que c'est par le nom Form_Error ?

   Oui, Form_Error tout comme Form_Load, Form_Open (et d'autres), sont des noms de procédures réservés à un usage bien défini.
   Dans un formulaire en mode création, affiches la fenêtre de ses propriétés et va à l'onglet 'Evénement'.
   A chaque événement correspond une procédure dont le nom et les arguments sont prédéfinis.
   Les procédures événementielles d'un formulaire sont de la forme Form_Evenement(...)
   Pour un contrôle elles seront de la forme NomDuControle_Evenement(...)
   Pour générer le corps de la procédure événementielle, en face de l'événement souhaité on selectionne "[Procédure événementielle]" dans la liste de choix et on clique sur le petit bouton [...] immédiatement à droite.

2. En faisant F1, je ne trouve pas acDataErrContinue et acDataErrDisplay (j'utilise Access 2003)

   Fais un recherche dans l'aide d'Access sur "Événement Error".
   Regarde la rubrique "Événement Error (Erreur) - Procédures événementielles"
   

3. Concernant le fonctionnement de la procédure, je crois comprendre qu'elle reçoit le code erreur dans "DataErr" le 1er argument quand elle est appelée par Access, puis elle met la valeur qui va bien dans "réponse" son deuxième argument. Mais après qu'est-ce qui se passe ? Je suppose qu'Access agit différement suivant la réponse, mais que fait-il ?

   Si on affecte AcDataErrDisplay à l'argument Response, Access affiche son message d'erreur habituel.
   Si on affecte acDataErrContinue à l'argument Response, Access n'affiche aucun message d'erreur.
   Il ne se passe rien de plus.
   Par exemple dans le cas d'une erreur liée à un doublon, dans les deux cas l'enregistrement n'a pas pu être ajouté ou modifié.
   L'action en cours (ajout ou modification d'enregistrement) n'a pas abouti.

4. Quel est l'usage des "#" devant #Const et #If

   #Const #If sont des directives de compilation utilisée dans la compilation conditionnelle.
   Si la condition se trouvant derrière #If est vraie, le code VB se trouvant à l'intérieur du bloc #If .. #End If est compilé.
   Si elle est fausse, le code n'est pas compilé. C'est comme s'il ne faisait pas partie du programme.

A+

[mouett]

Je te remercie beaucoup LedZeppII, pour toutes ces réponses que tu m'as apportées, ça m'aide énormément à avancer