Déverrouillage pavé numérique [Résolu]

[Depite]

Bonjour,

Je rencontre le même problème qu'ici avec peut-être quelques précisions.

Le phénomène se produit lors de la fermeture de certains formulaires (pas tous mais toujours les mêmes) et ce, quel que soit la méthode de fermeture :

• Fermeture directe du formulaire par le bouton Windows prévu à cet effet
• Suppression de l'instance d'objet formulaire s'il s'agit d'une instance
• Docmd.close acForm, ...

D'autre part, le verrouillage n'est pas "annulé" mais plutot inversé par rapport à son état au moment de l'ouverture du formulaire.

Enfin ce phénomène se produit systématiquement sur des postes Win 7 32 bit mais pas sur les postes Win 7 64 bits ni sur XP sp3.

Ma config :
Application .ADE sur runtime 2010, données SQL Server 2008

En espérant que ça aidera et que quelqu'un pourra nous fournir une solution ou, à défaut, une explication.

[loufab]

Bonjour,

Il y a également la FAQ où on peut trouver des choses interessantes.

http://access.developpez.com/faq/?pa...DesactAcpsLock

http://access.developpez.com/sources...rs#APICapsLock

En déduire le numlock n'est pas difficile. C'est le code 144 soit &H90 en hexa. (F2 dans le VBE)

Cordialement,

[Depite]

Bonjour,

Enfin du nouveau pour essayer d'éclairer notre lanterne: je parviens à reproduire le problème sur une construction simplifiée dans une base Access 2010.

je précise que je suis confronté au problème dans un projet 2010 mais il s'avère que l'anomalie est comparable dans une base de données Access.

Tout semble venir du fait que, pour assurer la fin de saisie du contrôle texte courant, j'envoie systématiquement une suite de touches Tab et maj+Tab avant d'appeler une éventuelle procédure de validation de saisie du formulaire.

Si je supprime la séquence Tab et maj+Tab il n'y a pas de modification de l'état du pavé numérique.

Pour reproduire le problème :

Téléchargez et décompactez le fichier VerNum.zip joint. Je travaille avec un antivirus à jour (Eset-node32).

si access 2010 est ouvert fermez toutes les occurences
Lancez Access
Ouvrez la base VerNum.acdb normalement à partir du Backstage access

Ouvrez le formulaire "Menu"
Cliquez sur le bouton [Affiche fenêtre]

Lorsque la fenêtre est ouverte appuyez sur la touche [F4], la fenêtre disparait, la première fenêtre réapparait et l'indicateur de verrouillage numérique du clavier change d'état - mais pas celui de la barre d'information d'Access!

Le phénomène se reproduit à chaque fermeture de la fenêtre "enfant" tant que l'on a pas fermé au moins une fois la fenêtre "Menu".

Il semble également que l'anomalie ne se produise que lors de la première ouverture de la base dans access: si on ferme la base en gardant Access ouvert puis qu'on réouvre la base le phénomène ne se reproduit pas.

Si, dans les mêmes circonstances, on utilise la touche [F5]pour fermer le formulaire il n'y a pas de modification de l'état de verrouillage du pavé numérique.

La Touche [F4] exécute sendKeys "{TAB}+{TAB}" avant de masquer la fenêtre, la touche [F5] ne le fait pas (voir la fonction FermerEnfant() du formulaire Menu )

Modes affichage testés :
- Documents à Onglets
- Fenêtres superposées

Je vais donc supprimer sendKeys "{TAB}+{TAB}" de mon application mais il va me rester le problème d'être sur que la zone en cours sera bien saisie car l'utilisation du ruban ne valide pas la zone en cours...

Merci à tous,
François

[Domi2]

Bonjour,

Envoyé par Depite

Bonjour Domi2,

Non, il n'y pas d'utilisation de SendKeys dans l'application.

A quoi sert exactement l'envoi des touches "{TAB}+{TAB}" ?

Domi2

[Depite]

Le sendkeys me permet d'assurer que la saisie en cours d'un contrôle actif de texte est bien complète avant de commencer la procédure de validation du formulaire courant.

Cette précaution est rendue nécessaire par le fait que la fermeture du formulaire est déclenchée par un bouton personnalisé du ruban et qu'il s'avère que l'accès au ruban en cours de saisie d'un contrôle texte ne conclue pas cette saisie.
En exécutant ce double TAB je suis sur que la saisie du champ courant est terminée et aura éventuellement déclenché ses propres événements de validation avant la procédure de validation du formulaire.

Je suis bien évidemment preneur d'une méthode moins "barbare" que je dois de toute façon abandonner, ce qui va me provoquer des problèmes de validation !

[Domi2]

Je pense que la meilleure "pratique" consiste à utiliser les événements du formulaire qui vont bien.

Pour tout ce qui est test de saisie ou de plausibilité, Avant Maj est pour moi le plus approprié.

Exemple :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Private Sub Form_BeforeUpdate(Cancel As Integer)
 
    'On Error...
 
    'Tests de plausibilité
    If Not IsDate(Me.txtAdhDateAdhesion) Then
 
        MsgBox "La date d'adhésion doit obligatoirement être saisie !", vbInformation + vbOKOnly
 
        Me.txtAdhDateAdhesion.SetFocus
 
        'Annulation de l'événement
        Cancel = True
 
        Exit Sub
 
    End If
 
    'Etc..

Domi2

[Depite]

Pas dans mon cas car je veux procéder à des contrôles AVANT l'événement form_beforeupdate.

Hors, je n'ai pas encore eu le temps de vérifier et ça ne sera plus pour aujourd'hui, mais il me semble que l'état .dirty du formulaire n'est pas modifié tant que la zone de texte en cours de saisie (à supposer que ce soit le premier champ modifié) n'est pas validée.

[Domi2]

Non, le formulaire est modifié dès que tu saisis un caractère, par exemple...

Envoyé par Depite

Pas dans mon cas car je veux procéder à des contrôles AVANT l'événement form_beforeupdate.

Je ne vois pas vraiment l'utilité, puisque tu peux l'annuler. Pour info, il est encore tout à fait possible, à ce stade, de modifier des valeurs de champs ou de demander à l'utilisateur de valider une action, par exemple.

Mais pour te répondre de manière plus pertinente, il faudrait que tu détailles plus précisément ce que tu désires faire avant d'enregistrer les données courantes de ton formulaire.

Domi2

[Shanur]

A mon avis la fonction, "SendKey" est buggée.

J'ai une solution qui fonctionne avec Acces 2007 et Windows Vista.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Private Declare Sub keybd Lib "User32" Alias "keybd_event" _
  (ByVal bVk As Byte, ByVal bScan As Byte, ByVal dwFlags As Long, _
  ByVal dwExtraInfo As Long)
Public Sub LangueClavierGrec(Clavier As Boolean)
 
      keybd 17, 0, 0, 0
      keybd 49, 0, 0, 0
      keybd 17, 0, 2, 0
      Clavier = True
 
End Sub
Public Sub LangueClavierFrancais(Clavier As Boolean)
 
 
      keybd 17, 0, 0, 0
      keybd 48, 0, 0, 0
      keybd 17, 0, 2, 0
      Clavier = False
 
End Sub

En mode système, Ctrl 0 est le clavier français et Ctrl 1 est le clavier grec.

Et pour les puristes qui ne manqueront pas de poser la question, j'utilise cette fonction en lieu et place de "Langue clavier" de la zone de texte parce que j'utilise un clavier belge et que "Langue Clavier" me restaure un clavier français et qu'il y a des différences de touches entre les deux types de clavier.

Maintenant, il reste à voir si cette librairie "User32" est disponible sur tous les systèmes d'exploitation