Discussion :

[DamKre]

Bonjour,

Mon formulaire F_Users est ce qu'il y a de plus classique.
Il présente une zone de liste déroulante Recherche_Utilisateur permettant, après mise à jour, d'aller à l'enregistrement souhaité. J'utilise la macro qui vient nativement.
Il y a aussi deux boutons de navigation (Précédent/Suivant)

J'ai des procédures dans Form_Current.

À l’ouverture, premier enregistrement, Form_Current se déclenche parfaitement.
Si je suis sur n'importe quel autre enregistrement, idem.
Dès que je reviens au premier enregistrement par Recherche_Utilisateur, Form_Current ne se déclenche pas. Si j'y viens par Btn_Precedent, tout va bien.
À noter que le contenu du formulaire (les champs) se chargement sans souci.

J'avoue que je n'y comprends rien.

Dans mes tests, si je ne passe par VBA, aucun souci.

Quelle serait la solution pour faire fonctionner cette macro sur le premier enregistrement ?

Je suis preneur de toute idée.

[micniv]

Bonjour,
Cet événement se produit à la fois lors de l'ouverture d'un formulaire ET lorsque le focus passe d'un enregistrement à un autre
Ici, le bouton Recherche_Utilisateur se trouve dans le formulaire et par consequent l'ordre "d'aller au premier ajustement" ne fait que changer la source du formulaire actuel affiché mais ne déclenche pas un nouvel affichage du form et donc de l'activation de l'evt form_current . Mais dans le code de Recherche_Utilisateur, tu peux forcer ce déclenchement en y insérant la ligne

Code :

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

1
2
 
call form_current()

[DamKre]

Bonjour,

Je te remercie de la réponse.

Je dois cependant m'être mal exprimé.

La liste déroulante Recherche_Utilisateur utilisait une macro, pas VBA.
Les procédures de la macro sont celles proposées nativement par Access 2007.
Cette macro pose problème uniquement lorsque je suis dans un autre enregistrement et que je sélectionne le premier dans la liste.

Si je supprime la macro et que j'utilise du VBA, aucun souci constaté.

Sauf erreur de ma part, on ne peut pas utiliser call Form_current dans une macro.

[argyronet]

Bonjour,

Une macro peut appeler une fonction mais pas une procédure et pour un événement, sous conditions seulement.

Sur le principe, appeler le Form_Current dans une macro peut s'exécuter en la nommant "OnCurrent" sur le nom de la macro ou sur [Procédure événementielle], mais bon, comme le formulaire le déclenche nativement selon le contexte... euh.

La difficulté est qu'il faut savoir gérer l'ordre de ces événements car Form_Current se produit soit à l'ouverture d'un formulaire soit lorsque le focus passe d'un enregistrement à un autre et ce avant oui après d'autres événements (Open, Load, etc...) mais avant l'affichage du 1er enregistrement ou de l'enregistrement suivant. Et si peu que vous fassiez autre chose (Requery ...) sur un autre événement, ça peut coincer.

Donc si cela ne se déclenche pas, c'est qu'Access ne se trouve pas confronté à l'une de ces conditions.

Argy

[DamKre]

Bonjour,

Ce problème n'étant pas résolu, et se produisant dans nombre de situations similaires pour les formulaires (même si aucune modification sur l'enregistrement), voici par exemple ce qu'il y a dans F_Users.

Macro "Modifiable_AccesUtilisateur" (déclenchée sur "Après MàJ"):

Action	Arguments
SurErreur	Atteindre: Suivant
RechercherEnregistrement	; ; Premier; ="[Usr_Login] = " & "'" & [Screen].[ActiveControl] & "'"
DéfinirValeur	[Modifiable_AccesUtilisateur]; ""

Cette macro fonctionne bien.

Procédure VBA:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
Private Sub Form_Current()
On Error GoTo Erreurs
 
RappelUtilisateur.Caption = Nz("Utilisateur: " & Me!Usr_Login, "")
 
Exit Sub
 
Erreurs:
Select Case err.Number
    Case Else
        MsgBox err.Description, vbCritical
End Select

Ai-je loupé quelque chose?
Il me semble qu'il n'y ait aucune action entre.

[EricDgn]

Bonjour,

J'écrirais plutôt ainsi cette instruction:

Code :

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

RappelUtilisateur.Caption = "Utilisateur: " & Nz(Me!Usr_Login, "")

Cordialement.

[DamKre]

Bonjour,

J'écrirais plutôt ainsi cette instruction:

Code :

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

RappelUtilisateur.Caption = "Utilisateur: " & Nz(Me!Usr_Login, "")

Cordialement.

Bonjour,
Merci d'avoir pris le temps de répondre.
Le fait de prévoir RappelUtilisateur.Caption = Nz("Utilisateur: " & Me!Usr_Login, "") était le comportement voulu.
Cela étant, ce que tu proposes ne résout pas le problème du premier enregistrement.
Bonne journée.

[micniv]

Cela étant, ce que tu proposes ne résout pas le problème du premier enregistrement.

Pour assurer la mise à jour du 1er enregistrement , déclenche la mise jour au chargement du form

Code :

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

call form_load()

Le fait de prévoir RappelUtilisateur.Caption = Nz("Utilisateur: " & Me!Usr_Login, "") était le comportement voulu.

alors tu peux essayer :

Code :

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

iif nz( Me!Usr_Login) <>"", RappelUtilisateur.Caption = Nz("Utilisateur: " & Me!Usr_Login, , RappelUtilisateur.Caption = & ''" ) t

[User]

Bonjour,
Voir aussi peut-être au niveau du login du 1er enregistrement, s'il ne contient pas un caractère spécial, genre une apostrophe.
Vu que vous faites une recherche.
Cdlt

[argyronet]

Bonjour,


De manière générale, lorsque l'on navigue avec des boutons de navigation Suivant et Précédent dans un formulaire, il y a automatiquement un rafraîchissement des données ; donc ton contrôle "Label" doit se mettre à jour avec l'enregistrement correspondant à ton champ "[Usr_Login]"...
Là, je pense qu'une de tes procédures verrouille quelque chose qui empêche le déclenchement de l'événement...

Dans l'absolu, il ne faut pas chercher à appeler "Form_Current" mais plutôt faire en sorte que "Form_Current" appelle lui-même, une procédure privée au sein de ta classe de formulaire...

Quand tu écris :
>>>> Dès que je reviens au premier enregistrement par Recherche_Utilisateur, Form_Current ne se déclenche pas
C'est pour ainsi dire normal car il n'y a pas eu de d’événement provoqué par cette navigation.


Pour ton Label...
Par exemple ; mais là, c'est pseudo théorique - je ne coderais pas cela comme ça..., mais d'un point de vue structurel c'est le type de syntaxe qu'il faut adopter ;

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
34
35
36
37
38
39
 
 
Private Sub Form_Current()
Dim blnErreur As Boolean, strDescription As String, strTitre As String
 
    Call RafraichirUtilisateur(blnErreur, strDescription, strTitre)
 
    If blnErreur Then
        Err.Raise 94, strTitre, strDescription
    End If
 
Sortie:
    Exit Sub
 
Erreurs:
    MsgBox strDescription, vbCritical, strTitre
    Resume Sortie
End Sub
 
Private Sub RafraichirUtilisateur(ByRef Erreur As Boolean, ByRef Description As String, ByRef Titre As String)
Dim vntUser                                            As Variant
 
    On Error GoTo Erreurs
    vntUser = Me!Usr_Login
    If Not IsNull(vntUser) Then
        RappelUtilisateur.Caption = Nz("Utilisateur : " & vntUser, "")
        Erreur = False
    Else
        Err.Raise 94, "Aucun utilisateur connu", "Il n'existe aucun utilisateur avec ce compte !"
    End If
Sortie:
    Exit Sub
 
Erreurs:
    Erreur = True
    Description = Err.Description
    Titre = Err.Source
    Resume Sortie
End Sub

Pour ce qui est de la recherche issue de ta liste déroulante, il faudrait adopter un code spécifique mais qu'il n'est pas encapsulé dans l'événement Form_Current, sinon jamais il ne sera levé :

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
Private Sub RechercherUtilisateur(ByVal Login As String)
Dim rs                                                 As DAO.Recordset
Dim strCriteria                                        As String
 
    On Error GoTo ErreurRechercherUtilisateur
 
    strCriteria = "[Usr_Login] = '" & Login & "'"
    Set rs = Me.RecordsetClone
    rs.FindFirst strCriteria
    If Not rs.NoMatch Then
        Me.Bookmark = rs.Bookmark
    Else
        'Peu probable mais bon...
        Err.Raise 94, "Pas de correspondnace", "Eh bah y a personne qui est connu sous ce compte dans la base"
    End If
 
    On Error GoTo 0
SortieRechercherUtilisateur:
    Set rs = Nothing
    Exit Sub
 
ErreurRechercherUtilisateur:
    MsgBox Err.Description, 48, Err.Source
    'On retourne sur le 1er
    DoCmd.GoToRecord acDataForm, Me.name, acFirst
    Resume SortieRechercherUtilisateur
End Sub

Argy

[User]

Bonjour,

À l’ouverture, premier enregistrement, Form_Current se déclenche parfaitement.
Si je suis sur n'importe quel autre enregistrement, idem.
Dès que je reviens au premier enregistrement par Recherche_Utilisateur, Form_Current ne se déclenche pas. Si j'y viens par Btn_Precedent, tout va bien.
À noter que le contenu du formulaire (les champs) se chargement sans souci.

Ah ok, désolé j'ai répondu trop vite :

c'est juste l'événement Form_Current qui ne se déclenche pas pour le 1er enregistrement, mais on y accède bien. J'ai en effet pu reproduire votre souci en mettant un msgbox dans le code form_current.

D'après Gemini :

C'est le paradoxe classique d'Access : l'enregistrement change visuellement, mais techniquement, Access considère qu'il n'y a pas eu de "mouvement" si vous étiez déjà sur le premier enregistrement (même si vous aviez navigué ailleurs entre-temps ou si la macro force le retour).

Voici l'explication précise : Si vous utilisez une macro pour faire un RechercherEnregistrement vers l'enregistrement où vous vous trouvez déjà, Access "saute" l'étape Form_Current car il estime qu'il n'y a pas de nouvel enregistrement à charger en mémoire.

Dans ce cas il faudrait mettre à jour l'étiquette depuis l'événement après-maj de la liste si vous souhaité absolument conserver la macro :

Configuration de l'action dans la macro :

Ajouter une nouvelle action : Cherchez DéfinirPropriété (Si vous ne la voyez pas, vérifiez que le bouton "Afficher toutes les actions" est activé dans le ruban).

Nom du contrôle : Tapez le nom exact de votre étiquette : RappelUtilisateur.

Propriété : Sélectionnez Caption (ou tapez Légende selon votre version).

Valeur : C'est ici qu'on utilise l'expression pour récupérer le login actuel :

Tapez : ="Utilisateur: " & [Usr_Login]

En VBA comme proposé il n'y a pas besoin alors pourquoi s'en passer

[DamKre]

Bonjour User.

Cela me rassure que vous avez réussi à reproduire le souci.

Lorsque vous dites:

En VBA comme proposé il n'y a pas besoin alors pourquoi s'en passer

cela veut-il dire qu'il faut au final utiliser VBA et non une macro?

Je voulais réutiliser une macro car cela me semblait alléger la base et le code...

[User]

Bonjour,

Oui je vous conseille d'utiliser VBA, car ça n'alourdit pas la base, en plus vous pourrez réutiliser ce type de code et vous familiariser avec ce langage qui offre beaucoup plus de possibilités que les macros.

Cdlt

[DamKre]

Merci.

Avec VBA, plus de souci, comme prévu.

Pour terminer, et en reprenant mes anciennes notes, voici le code (je prends les formulaires par ordre alphabétique, j'adapterai les Id et les Recherche pour les formulaires):

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
Private Sub RechercheCitoyen_AfterUpdate()
On Error GoTo Erreurs
 
'Rechercher l'enregistrement correspondant
Dim rs As DAO.Recordset
 
Set rs = Me.Recordset.Clone
rs.FindFirst "Id_Cit=" & Me!RechercheCitoyen
Me.Bookmark = rs.Bookmark
 
'Réinitialiser
RechercheCitoyen = ""
 
Exit Sub
 
Erreurs:
Select Case err.Number
    Case 94
        Resume Next
    Case Else
        MsgBox err.Description, vbCritical, "Mon Programme"
End Select
 
End Sub

En reprenant mes anciennes notes, j'utilisais Dim rs As Object mais j'ai mis Dim rs As DAO.Recordset suite aux commentaires de argyronet ci-avant.
Quelle est la différence ?

Est-il utile de prévoir également l'erreur 3021?

Merci de vos regards attentifs.

[User]

Bonjour,

...
En reprenant mes anciennes notes, j'utilisais Dim rs As Object mais j'ai mis Dim rs As DAO.Recordset suite aux commentaires de argyronet ci-avant.
Quelle est la différence ?

En déclarant tes variables dans un type d'objet précis (ex : Dim rs As DAO.recordset) le code devrait être plus rapide à l'exécution.
Autre avantage, tu peux lister les propriétés et méthodes des variables au cours de l'écriture de ton code car Access sait précisément de quel type d'objet il s'agit. Enfin tu peux vérifier les erreurs de frappe sur une méthode ou une propriété au moment de compiler le code et donc avant son exécution.

Au niveau référencement DAO est coché par défaut dans Access, donc pas de souci de ce côté là.

L'idée par la suite serait de créer avec ton code une procédure générique dans un module standard que tu puisses ensuite réutiliser dans le même contexte sur différents formulaires.

[DamKre]

Rebonjour,

Donc, pas d'erreur sur le code que j'ai indiqué?
Je prévois bien l'erreur 3021, puisqu'on a un DAO.Recordset ?

Bonne soirée !

[User]

Bonjour,

Pour éviter ce genre d'erreur je te conseille plutôt d'utiliser la structure conditionnelle :

Code :

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

1
2
3
4
5
If Not rs.NoMatch Then
    Me.Bookmark = rs.Bookmark
else
    MsgBox("Aucun d'enregistrement de trouvé !")
end if

Comme dans le code d'Argy.

[argyronet]

En reprenant mes anciennes notes, j'utilisais Dim rs As Object mais j'ai mis Dim rs As DAO.Recordset suite aux commentaires de argyronet ci-avant.
Quelle est la différence ?

Ainsi que le dit User, le fait de déclarer un objet en le qualifiant vous permet d'avoir un code propre et aussi de bénéficier de l'intellisense dynamique au moment où effectivement vous écrivez votre code.
Lorsque vous déclarez un élément comme un Recordset en Object, vous risquez de commettre des erreurs de syntaxe car vous êtes obligés de connaître toutes les méthodes et propriétés par cœur.
Si un jour vous passez au Java, vous aurez beaucoup moins de liberté.
Du coup, autant prendre les bonnes habitudes tout de suite.

Pourquoi faut-il qualifier ?
Parce que vous êtes susceptibles d'avoir deux références dans une même application pour déclarer des objets d'accès aux données : il y a une différence notoire entre :

Code :

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

1
2
Dim oRS As DAO.Recordset
Dim oRS As ADO.Recordset

Les deux objets sont des objets RecordSet et manipulent tous les deux des données.
Simplement il y en a un qui est exclusivement réservé au moteur Microsoft Access et l'autre qui est en mesure d'attaquer d'autres technologies de base de données comme SQL Server, Oracle, MySQL ou etc.
Ils possèdent tous deux quasiment les mêmes méthodes et propriétés mais ne s'utilisent pas du tout de la même façon.
Pour autant, si vous avez les deux références dans votre projet en imaginant que votre application interroge à la fois une base Oracle et une base Access avec des tables liées, vous auriez besoin des deux déclarations et de prêter attention aux priorités de références.

C'est pareil si vous utilisiez la technologie Automation et que votre application utilise à la fois Microsoft Visio et Microsoft Word.
Dans Microsoft Visio au même titre que Microsoft Word, vous avez bien un objet Document.
Si vous ne qualifiez pas vos déclarations avec Word.Document ou Visio.Document, selon l'ordre de priorité des références (parce que il y a cela aussi à considérer) vous ne pourriez pas appliquer certaines méthodes à l'un ou à l'autre objet et c'est pour ça qu'il est utile de qualifier.

Est-il utile de prévoir également l'erreur 3021?

De manière générale, il faut toujours monter une gestion d'erreur bien musclée et subséquente à n'importe quel type d'erreurs pouvant être rencontré par l'exécution de la procédure en cours.
L'erreur 3021 est juste un exemple d'enregistrement non trouvé.

Si effectivement vous voulez simplifier le code et ne vous contenter d'un .EOF qui va retourner True, vous pouvez vous contenter effectivement d'un simple :

Code :

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

MsgBox"Bah, j'ai rien trouvé !", vbExlamation

Disons qu'en tant que professionnel, je vous ai émis l'idée du Err.Raise pour que vous preniez bonne note de cette façon de coder qui est vraiment miraculeuse lorsqu'elle est bien employée.

Je vous donne une petite astuce juste pour le fun ; si vous voulez connaître à coup sûr une erreur Access liée à un numéro, vous tapez tout simplement dans la fenêtre du débogage :

Code :

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

?AccessError(3021)

et vous appuyez sur entrée.

Vous pouvez également vous faire une petite procédure privée locale dans laquelle vous pouvez faire un Debug.Print pour lister énumérer toutes les erreurs probables.

Argy

[DamKre]

Bonjour,

Merci pour toutes les précisions.

Dès lors, il me semble qu'avec ceci tout est OK:

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
Private Sub RechercheCitoyen_AfterUpdate()
On Error GoTo Erreurs
 
'Rechercher l'enregistrement correspondant
Dim rs As DAO.Recordset
 
Set rs = Me.Recordset.Clone
rs.FindFirst "Id_Cit=" & Me!RechercheCitoyen
 
If Not rs.NoMatch Then
    Me.Bookmark = rs.Bookmark
Else
    MsgBox "Aucun enregistrement correspondant!", vbExclamation, "Mon Programme"
End If
 
'Réinitialiser
RechercheCitoyen = ""
 
Exit Sub
 
Erreurs:
Select Case err.Number
    Case 94
        Resume Next
    Case Else
        MsgBox err.Description, vbCritical, "Mon Programme"
End Select
 
End Sub

Vous me confirmez ?

[User]

Bonjour,

L'erreur 94 peut venir par exemple d'une liste déroulante où rien n'est sélectionné :
impossibilité de construire une chaîne avec une valeur Null dans le critère du findfirst.

Donc il vaut mieux essayer de gérer ce problème en amont en testant If Not IsNull(Me.RechercheCitoyen) then :

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
Private Sub RechercheCitoyen_AfterUpdate()
On Error GoTo Erreurs
 
'Rechercher l'enregistrement correspondant
Dim rs As DAO.Recordset
 
If Not IsNull(Me.RechercheCitoyen) then
 
    Set rs = Me.RecordsetClone
 
    rs.FindFirst "Id_Cit=" & Me.RechercheCitoyen
 
    If Not rs.NoMatch Then
        Me.Bookmark = rs.Bookmark
    Else
        MsgBox "Aucun enregistrement correspondant!", vbExclamation, "Mon Programme"
    End If
 
end if
 
Sortie: 
    'Réinitialiser
    ' Me.RechercheCitoyen = ""
    Set rs = Nothing ' libère la mémoire
 
Exit Sub
 
Erreurs:
    MsgBox err.Description, vbCritical, "Mon Programme"
    Resume Sortie
 
End Sub

Le Resume Sortie permet de sortir proprement après le traitement de l'erreur (comme dans le code d'argy).

J'ai ôté l'initialisation de la liste. Quand tu navigues tu peux synchroniser ta liste avec l'enregistrement courant en mettant ce code sur l'événement activation de ton formulaire :

Code :

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

1
2
3
4
5
Private Sub Form_Current()
 
Me.RechercheCitoyen = nz(Me.[Id_Cit],0)
 
End Sub

Cdlt