Discussion :

[Geache]

Bonjour,

Je ne suis pas certain que la discussion soit dans le bon forum mais mon problème survient dans les formulaires et, par conséquent, il me semblait que c'était la rubrique la plus appropriée.

Cela fait quelques jours que je cherche une solution sur la toile sans succès. Voici mon problème :

Je fais de la maintenance sur une application développée en Access 2010 sous Windows 7 pour l'application cliente et MS SQL server 2008 pour la base de données. L'application tourne sur près de 70 postes de travail.

Jusque là, tout fonctionnait correctement. Mais depuis quelques temps, pour une raison inconnue, et de façon tout à fait aléatoire, quelque soit le PC client, la touche CapsLock change de statut, l'application se fige et elle doit être interrompue par un ctrl + alt + del avant d'être relancée.

Quelqu'un aurait-il déjà rencontré ce phénomène ? Auriez-vous une piste de recherche à me proposer ?

Je vous remercie d'avance pour vos contributions et je vous souhaite une excellente journée.

[EricDgn]

Aucune suggestion à ce que je vois, alors celle-ci, on ne sait jamais: ajouter l'un ou l'autre DoEvents en particulier après usage de SendKeys ou appel à un objet externe à Access. Sans garantie !
Bonne chance.

[Geache]

Bonjour Eric,

Le système de DoEvents ne changerait rien, je pense, en ce sens que lors du passage de ACCESS 2003 à ACCESS 2007, j'avais déjà rencontré ce problème, non pour le CAPS LOCK mais pour le NUM LOCK. J'ai donc passé un temps fou à corriger toutes les lignes de codes où apparaissaient des Sendkeys pour les remplacer par des instructions qui n'engendraient plus de problème. Par exemple, un Sendkey {Enter} que je remplaçais par un call evenement_click.

La, le problème me semble différent. Le caps lock change de status, certes, mais ce qui me gène le plus, c'est que l'application fige et qu'il est impossible de faire autre chose qu'un CTRL + ALT + DEL.

Sur la toile, je ne trouve toujours personne qui ait l'air d'avoir rencontré ce problème de près ou de loin. En attendant, le client continue de râler avec son CTRL + ALT + DEL.

Toutefois, nous allons tester une possibilité qui est la suivante :

Par soucis de facilité, notre équipe a développé l'application à partir d'une version ACCESS 2010 en anglais.
Le client, lui, a installé une version ACCESS 2010 en néerlandais.

Ce qui nous fait penser qu'il y a un problème de compatibilité entre les deux versions linguistiques, c'est que, pour ce client, nous avons dû modifier l'utilisation de certaines fonctions en les remplaçant par des procédures créées de toutes pièces. Par exemple, une fonction modulo fonctionne sans aucun problème en anglais, mais le système crashe lorsque nous faisons tourner l'application en néerlandais.

Nous allons donc réinstaller une version full access 2010 en anglais sur le pc du client et voir ce qu'il en est lorsque nous exécutons notre application.

Cela nous paraît un peu bizarre, mais nous allons tester pour voir quel résultat nous obtiendrons.

Je vous tiendrai au courant du résultat de notre expérience.

Bonne journée et merci de ta suggestion.

[Geache]

Bonjour,

Je reviens sur cette discussion. Nous avons réinstallé MSACCESS 2010 en anglais sur un poste client.

Sans résultat, le problème de Caps Lock est toujours présent.

Nous sommes sur une autre piste. Je vous tiendrai au courant.

Bonne journée.

[kiki29]

Salut, dans un autre contexte, pour remédier au problème intermittent lié aux SenKeys multiples que les DoEvents ne résolvent pas toujours et qui se traduit par une désactivation des NumLock CapsLock ScrollLock PauseLock :
Acrobat Reader Copier/Coller le texte d'un PDF dans une feuille Excel via des SendKeys.

Qui par la suite à été résolu comme ceci

[Geache]

Bonjour,

Après moultes péripéties, le problème semble enfin résolu.

Je ne sais pas trop comment je vais vous expliquer ce que nous avons finalement éradiqué, mais je vais tenter de le faire.

1) Dans l'application, nous avions, en reliquat de programmations antérieures, une macro AutoKeys qui, pour les touches de fonctions de F2 à F12, faisait appel à un module FunctieToetsen (Touches de fonction en français). Chaque touche de fonction lançait une commande RunCode autoFx() (avec x le numéro de la touche de fonction).

2) Le module FunctieToetsen était composé de fonctions codées comme ceci :

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
Function autoF2()
On Error GoTo ErrorHandling
 
Dim frmHuidigFormulier As Form
 
    Set frmHuidigFormulier = Screen.ActiveForm
 
    Select Case frmHuidigFormulier.name
        Case Is = "frmschakelbordHoofd":
'
'           La série de commandes appropriées
'
            Exit Function
        Case Is = "FrmSchakelbordReceptie":
'
'           La série de commandes appropriées
'
            Exit Function
FinFunction:
   Exit Function
 
ErrorHandling:
    If err.Number <> 0 Then
        strProcNaam = "Functietoetsen - autoF2"
        Call errorsolution(strProcNaam)                      ' Procédure alimentant un fichier log interne des erreurs de l'application
    End If
    Resume FinFunction
End Function

3) Nous avons commencé par supprimer cette macro et le module correspondant pour les remplacer par une utilisation des propriétés événementielles KeyPreview, On Key Up, On Key Down, etc...

4) Aie aie aie... Heureusement nous n'avions pas modifié l'ensemble des formulaires, nous n'en avons testés qu'un ou deux, parce que, selon le type de clavier utilisé par nos clients, les touches de fonctions F7 à F12 provoquent parfois des réactions totalement imprévues et autres que les procédures que nous avions mises en place.

5) Bref, Roll back et passage du code en revue dans le module FunctieToetsen.

6) ça et là, il restait quelques SendKeys. Par expérience, il suffit d'un seul SendKeys pour que la touche NumLock (et à fortiori CapsLock) bascule de l'état Verrouillé à non-Verrouillé. Nous avons donc éradiqué les derniers SendKeys de ce module. Nous en assumons la faute en ce sens que nous pensions ce module obsolete et qu'à ce titre, nous ne l'avions pas réexploré (erreur de documentation de l'application). Mea culpa, mea maxima culpa.

Après quelques semaines de tests en production chez nos clients, le problème semble enfin solutionné.

Merci au passage à Kiki29 en particulier grâce auquel je suis tombé sur un post faisant référence à MZ-Tools. Outil précieux pour trouver toutes les occurences d'une instruction et toutes les instructions appelantes d'une procédure.

Et merci à tous ceux qui m'ont lu ainsi qu'à ceux d'entre-vous qui ont tenté de me venir en aide.