[AC-2007] Mise à jour impossible d'une combo box [Résolu]

[dumas.blr]

Bonjour,

Dans un formulaire, J'ai créé une combo box que j'ai relié à un contrôle caché

Lorsque j'ouvre le formulaire directement, il n'ya pas de problème pour mettre à jour la combo box : c'est à dire que la liste s'affiche et je peux sélectionner un élément de la liste

Pièce jointe 69875

Les événements _before_update et _after_update se déclenchent bien



Par contre, lorsque je l'ouvre à partir d'un autre formulaire indépendant (ouverture en acmodal) , la liste s'affiche,mais je ne peux pas sélectionner un élément de la liste, la combo box refuse la mise à jour, et j'ai en bas dans la barre d'état un message 'impossible de mettre à jour recordset'.

Pièce jointe 69876

Là, les événements ne se déclenchent pas.

Est-ce que lorsque l'on ouvre une nouvelle fenêtre indépendante sur une fenêtre indépendante, il n'y a un processus qui empèche le transfert de focus sur ce nouveau formulaire ?

[GAYOT]

Bonjour
Si tu mets ton formulaire en mode Modal, il va garder le focus jusqu'à ce qu'il soit fermé.

[dumas.blr]

Bonjour Jean-Damien,

Cela signifie-t-il que je doit d'abords fermer le formulaire appelant avant de pouvoir transférer le controle à mon formulaire appelé ?
Y a -t-il un biais pour inactiver le formulaire appelant sans le fermer, puis le réactiver à la fermeture du formulaire appelé ?

[GAYOT]

J'avoue ne pas avoir été confronté à ce genre de problème.
As tu déjà essayé d'ouvrir ton formulaire avec les propriétés "Indépendant" à "oui" et "Modal" à "non".
Pour voir si tu as la même chose.

[dumas.blr]

Bonjour Jean-Damien.

même comportement en mettant la popriété "modal" à non.

J'ai l'impression qu'Access passe par un autre type d'API quand il utilisa des fenêtres indépendantes/modales.

Si j'utilise cette méthode, c'est que je souhaite que les utilisateurs (qui ne sont absolument pas informaticiens, et des personnes plutôt agées) ne puissent faire aucune fausse manipulation. Or, la navigation par onglet ne permet justement pas de sécuriser l'obligation d'aller sur un écran et pas un autre !

[GAYOT]

Après un test rapide, j'ai réussi à partir d'un formulaire indépendant et modal à non seulement rafraichir, mais changer la valeur d'une CboBox d'un autre formulaire en Vba. Je peux modifier de l'extérieur par contre je ne peux pas retourner sur la CboBox directement (Modal oblige).
Si je mets la propriété modale à Non, pas de problème.

[dumas.blr]

Bonjour,
J'ai tracé les différents évènements, et voila ce que j'ai trouvé

Sans mon formulaire appelant, j'ai l'instruction :

Code :

1
2
3
4
Private Sub CmdEmargement_Click()
Parametres = Me.ENR
- DoCmd.OpenForm "frmPointage", , , "ENR=" & Parametres
End Sub

voici les évènements que je trace :
- formulaire appelant : bouton clic -> - formulaire frmPointage_open
- formulaire frmPointage_open
- formulaire frmPointage_load
- formulaire frmPointage_current
- Puis retour dans le sub du formulaire appelant, sans aucune action de ma part.

J'ai modifié mon code en

Code :

DoCmd.OpenForm "frmPointage", , , "ENR=" & Parametres, acFormEdit, acDialog

même résultat !
Par contre, je viens de l'apercevoir que dans mon formulaire appelant, j'ai un évènement Form_Timer.
Est-ce quela ne force pas le retour au focus de l'appelant ?

[dumas.blr]

Bonjour,

J'ai trouvé la solution à mon problème.

Le formulaire appelant et le formulaire appelé avaient la même table en datasource; et le formulaire appelant avait été paramétré en verrouilage général (onglet "données" de la fenêtre propriété sur le formulaire).
Il m'a suffit que je change le verrouillage sur "enregistrement modifié pour que tout rentre dans l'ordre).

Merci à ceux qui ont pris le temps pour essayer de m'aider.