Nous avons vu il y a quelques jours comment accéder aux données stockées sur une pointeuse Safescan TA-855 (modèle avec écran noir et blanc, lecteur d’empreinte digitale, identification par badge RF, etc). Si vous ne l’avez pas encore fait n’hésitez pas à lire la première partie qui explique comment se connecter à l’appareil et lire le journal des événements global. Nous allons aujourd’hui voir comment programmer simplement la gestion des événements, lors de la connexion par exemple.
Événement lors de la connexion
Lorsqu’on se connecte à la pointeuse, l’événement OnConnected est toujours émis. Il est donc possible d’intercepter celui-ci de manière automatique dans Windev. Mais comment doit-on faire cela ? C’est plutôt simple : on utilise la fonction AutomationEvénement() pour brancher une procédure du code sur un événement de notre objet automation précédemment créé (voir l’article précédent). On peut l’appeler lors du chargement du projet ou même de notre fenêtre principale.
Les paramètres à indiquer dans l’ordre sont : la procédure qui devra être exécuter lors de la réception de l’événement, l’objet automation en question, et le nom exact de l’événement (attention car la casse est importante). Dans l’exemple ci-dessus, on a demandé à ce que la procédure « lproc_onConnected() » nous signale lorsque le PC est bien connecté à la pointeuse – OnConnected. Dans cette fameuse procédure on affiche simplement un message sous forme de « Toast » grâce à ToastAffiche().
Événement lors de la déconnexion
Il existe également l’événement OnDisConnected d’après la documentation. Cependant, même lorsqu’on branche la procédure à celui-ci, et qu’on se déconnecte de la machine, l’événement ne semble pas être intercepté. Pourtant il est indiqué que celui-ci est émis lorsque le PC est correctement déconnecté de l’appareil.
Événement lors du pointage
Nous avons également souhaité récupérer les données de la pointeuse de manière automatique lorsqu’un utilisateur pointe (que ce soit avec le lecteur d’empreintes ou bien avec sa carte RF). Ces événements sont ajoutés dans un tableau d’une fenêtre fille MDI. Ils sont temporaires : pour savoir comment les récupérer dans la mémoire de la pointeuse, n’hésitez pas à regarder l’article précédent.
Les événements comme OnAttTransaction doivent être « enregistrés » pour être interceptés, d’après la documentation. On utilise toujours AutomationEvénement() pour brancher des procédures à ces derniers. Voici les étapes à réaliser :
- Appel de la fonction WLangage AutomationEvénement().
- Lors de la connexion on va enregistrer les événements avec la fonction RegEvent() de notre objet automation. En paramètre il faut indiquer le n° de la machine mais également le ou les événement(s) que l’on souhaite traiter (EventMask). La documentation donne tous les codes des événements que l’on peut utiliser. Pour en traiter plusieurs, il faut les combiner en effectuant une opération XOR. Si on souhaite tous les utiliser on peut indiquer la valeur 65535.
- La procédure qui va traiter cet événement reçoit 10 paramètres. En les typant en entier, vous obtiendrez une exception « le type vide ne peut pas être converti en entier« . C’est pourquoi nous n’avons pas indiqué de type.
- L’ID utilisateur qui pointe.
- Pointage invalide (1) / valide (0).
- Statut ; par exemple, 0 = entrée, 1 = sortie.
- Mode de vérification (0 = password, 1 = FP, 2 = Carte) .
- Année.
- Mois.
- Jour.
- Heure.
- Minute.
- Seconde.
- La procédure utilisée est locale à la fenêtre d’accueil mais nous ajoutons les données dans le champ Table d’une fenêtre MDI (possédant un alias) seulement si elle est ouverte. Pour cela les indirections sont très utiles.
Voici un exemple concret :1) Appel de AutomationEvénement() dans le code d’initialisation de la fenêtre d’accueil par exemple. Le premier paramètre correspond au nom de la procédure à brancher, le second à notre objet automation et enfin le troisième au nom exact de l’événement tel qu’on peut le voir via OLE/COM Object Viewer. Il est important de respecter la casse.
2) Après l’appel de Connect_Net() de l’objet automation, et uniquement si la connexion a réussi, on appelle RegEvent().
3) On a branché la procédure lproc_onAttTransaction() sur l’événement correspondant. Voici le contenu de la procédure. On remarque donc bien les 10 paramètres en entrée, sans type comme c’était prévu. On remplit le champ Table en insérant chaque fois une ligne au début, puis à l’aide des indirections on remplit chacune des colonnes.
Voici ce que cela donne comme résultat à l’exécution :
Bon développement à tous !
Bonjour Mr Vincent Lecomte
je cherche ton code source sur windev
merci
Salut Vincent, Comment vas tu? Juste te dire merci pour cette belle contribution.
J'ai suivi tes conseils et tout se passe bien.
Mon souci est que je souhaite utiliser ces fonctions pour plusieurs lecteurs connectés (2 à 5) en même temps, car avec un seul lecteur, ça passe bien mais avec plusieurs lecteurs sur le réseau, il ne marche qu'avec le dernier lecteur connecté. Les autres sont connectés mais les données ne sont pas interceptées.
Merci bien et porte toi bien.
Chaque machine n'a-t-elle pas un ID lorsqu'elle se présente sur le réseau ? Je ne sais plus vraiment dire et je n'ai plus de quoi tester… à mon avis il y a moyen d'intercepter selon un identifiant… ou alors il faut se connecter à chacune selon leur MAC ? …pistes à suivre, sans plus de conviction…
OK Merci bien Vincent. Je me suis rendu compte qu'il n'est pas possible d'intercepter plusieurs lecteurs en même temps dans la même fenêtre. Donc pour chaque lecteur, j'ouvre une autre fenêtre de l'application. ce qui signifie que si on a 5 lecteurs, l'application en multi-instance sera ouverte 5 fois. Chaque instance étant connectée à 1 lecteur pour intercepter les événements du lecteur qu'il connecte. Bon c'est une solution standard pour le moment en attendant une solution définitive…
MERCI
En effet 🙂