Bonjour,
J'ai un formulaire Access qui se rempli via un lecteur de code barre
(Code 39) . La douchette est connectée par le port USB. Pour une
meilleure automatisation, j'aurais besoin d'activer la fenêtre du
fichier access, dès que l'on utilise la douchette. Comment "écouter "
mon port usb , Si vous avez des pistes je suis preneur. D'avance merci
Pascal
Bonjour,
J'ai un formulaire Access qui se rempli via un lecteur de code barre
(Code 39) . La douchette est connectée par le port USB. Pour une
meilleure automatisation, j'aurais besoin d'activer la fenêtre du
fichier access, dès que l'on utilise la douchette. Comment "écouter "
mon port usb , Si vous avez des pistes je suis preneur. D'avance merci
Pascal
Bonjour,
J'ai un formulaire Access qui se rempli via un lecteur de code barre
(Code 39) . La douchette est connectée par le port USB. Pour une
meilleure automatisation, j'aurais besoin d'activer la fenêtre du
fichier access, dès que l'on utilise la douchette. Comment "écouter "
mon port usb , Si vous avez des pistes je suis preneur. D'avance merci
Pascal
Pogo a écrit, le 10/06/2011 10:49 :Bonjour,
J'ai un formulaire Access qui se rempli via un lecteur de code barre
(Code 39) . La douchette est connectée par le port USB. Pour une
meilleure automatisation, j'aurais besoin d'activer la fenêtre du
fichier access, dès que l'on utilise la douchette. Comment "écoute r"
mon port usb , Si vous avez des pistes je suis preneur. D'avance merci
Pascal
Bonjour,
Est-ce qu'une piste ne consisterait pas à vérifier si le port USB n e
serait pas en fait utilisé en émulation d'un port série ?
Sur la question on trouve ça :
http://www.cppfrance.com/forum/sujet-UTILISER-PORT-USB-COMME-PORT-SERIE _486689.aspx
qui s'avère fort lisible. Cela étant le numéro de port ne sera pe ut-être
pas le même chez toi.
Une fois que tu as réussi à te connecter à ta douchette comme si elle
était sur un port série tout bête, alors là on tombe dans un su jet
beaucoup plus classique, la communication par port série, j'imagine q ue
tu sauras te documenter dessus.
On peut imaginer une solution simpliste qui consiste à juste détect er
l'arrivée d'un caractère de la douchette, et à ce moment sélect ionner la
base, et ensuite laisser faire le pilote fourni, qui émule le clavier .
Mais si on fait ça j'appréhende un problème, c'est que le temps q u'on
sélectionne la fenêtre plusieurs caractères ont déjà été transmis. On
pourrait penser à passer la douchette une deuxième fois, mais les
caractères transmis, en émulation clavier, ont pu provoquer des
perturbations dans les autres applications.
Donc de deux choses l'une, soit tu trouves une astuce pour contourner c e
problème, soit tu trouves un moyen de désactiver le pilote qui ém ule le
clavier, tu potasses la communication par port série, et tu écris
toi-même la réception des caractères. Comme ça, comme tu sais o ù les
envoyer, tu peux ouvrir Access en DDE, créer ton enregistrement en
respectant les contraintes d'intégrité, ouvrir la fenêtre de cré ation
qui va bien ...
C'est vrai que c'est plus astreignant que d'utiliser l'émulation
clavier, mais au moins tu maîtrises bien la chose. Est-ce que la doc de
la douchette est bavarde ? Par exemple sur la possibilité d'ajouter d es
caractères devant la chaîne reçue ?
Pogo a écrit, le 10/06/2011 10:49 :
Bonjour,
J'ai un formulaire Access qui se rempli via un lecteur de code barre
(Code 39) . La douchette est connectée par le port USB. Pour une
meilleure automatisation, j'aurais besoin d'activer la fenêtre du
fichier access, dès que l'on utilise la douchette. Comment "écoute r"
mon port usb , Si vous avez des pistes je suis preneur. D'avance merci
Pascal
Bonjour,
Est-ce qu'une piste ne consisterait pas à vérifier si le port USB n e
serait pas en fait utilisé en émulation d'un port série ?
Sur la question on trouve ça :
http://www.cppfrance.com/forum/sujet-UTILISER-PORT-USB-COMME-PORT-SERIE _486689.aspx
qui s'avère fort lisible. Cela étant le numéro de port ne sera pe ut-être
pas le même chez toi.
Une fois que tu as réussi à te connecter à ta douchette comme si elle
était sur un port série tout bête, alors là on tombe dans un su jet
beaucoup plus classique, la communication par port série, j'imagine q ue
tu sauras te documenter dessus.
On peut imaginer une solution simpliste qui consiste à juste détect er
l'arrivée d'un caractère de la douchette, et à ce moment sélect ionner la
base, et ensuite laisser faire le pilote fourni, qui émule le clavier .
Mais si on fait ça j'appréhende un problème, c'est que le temps q u'on
sélectionne la fenêtre plusieurs caractères ont déjà été transmis. On
pourrait penser à passer la douchette une deuxième fois, mais les
caractères transmis, en émulation clavier, ont pu provoquer des
perturbations dans les autres applications.
Donc de deux choses l'une, soit tu trouves une astuce pour contourner c e
problème, soit tu trouves un moyen de désactiver le pilote qui ém ule le
clavier, tu potasses la communication par port série, et tu écris
toi-même la réception des caractères. Comme ça, comme tu sais o ù les
envoyer, tu peux ouvrir Access en DDE, créer ton enregistrement en
respectant les contraintes d'intégrité, ouvrir la fenêtre de cré ation
qui va bien ...
C'est vrai que c'est plus astreignant que d'utiliser l'émulation
clavier, mais au moins tu maîtrises bien la chose. Est-ce que la doc de
la douchette est bavarde ? Par exemple sur la possibilité d'ajouter d es
caractères devant la chaîne reçue ?
Pogo a écrit, le 10/06/2011 10:49 :Bonjour,
J'ai un formulaire Access qui se rempli via un lecteur de code barre
(Code 39) . La douchette est connectée par le port USB. Pour une
meilleure automatisation, j'aurais besoin d'activer la fenêtre du
fichier access, dès que l'on utilise la douchette. Comment "écoute r"
mon port usb , Si vous avez des pistes je suis preneur. D'avance merci
Pascal
Bonjour,
Est-ce qu'une piste ne consisterait pas à vérifier si le port USB n e
serait pas en fait utilisé en émulation d'un port série ?
Sur la question on trouve ça :
http://www.cppfrance.com/forum/sujet-UTILISER-PORT-USB-COMME-PORT-SERIE _486689.aspx
qui s'avère fort lisible. Cela étant le numéro de port ne sera pe ut-être
pas le même chez toi.
Une fois que tu as réussi à te connecter à ta douchette comme si elle
était sur un port série tout bête, alors là on tombe dans un su jet
beaucoup plus classique, la communication par port série, j'imagine q ue
tu sauras te documenter dessus.
On peut imaginer une solution simpliste qui consiste à juste détect er
l'arrivée d'un caractère de la douchette, et à ce moment sélect ionner la
base, et ensuite laisser faire le pilote fourni, qui émule le clavier .
Mais si on fait ça j'appréhende un problème, c'est que le temps q u'on
sélectionne la fenêtre plusieurs caractères ont déjà été transmis. On
pourrait penser à passer la douchette une deuxième fois, mais les
caractères transmis, en émulation clavier, ont pu provoquer des
perturbations dans les autres applications.
Donc de deux choses l'une, soit tu trouves une astuce pour contourner c e
problème, soit tu trouves un moyen de désactiver le pilote qui ém ule le
clavier, tu potasses la communication par port série, et tu écris
toi-même la réception des caractères. Comme ça, comme tu sais o ù les
envoyer, tu peux ouvrir Access en DDE, créer ton enregistrement en
respectant les contraintes d'intégrité, ouvrir la fenêtre de cré ation
qui va bien ...
C'est vrai que c'est plus astreignant que d'utiliser l'émulation
clavier, mais au moins tu maîtrises bien la chose. Est-ce que la doc de
la douchette est bavarde ? Par exemple sur la possibilité d'ajouter d es
caractères devant la chaîne reçue ?
Gloops a écrit, le 10/06/2011 21:40 :
> Pogo a écrit, le 10/06/2011 10:49 :
>> Bonjour,
>> J'ai un formulaire Access qui se rempli via un lecteur de code barre
>> (Code 39) . La douchette est connectée par le port USB. Pour une
>> meilleure automatisation, j'aurais besoin d'activer la fenêtre du
>> fichier access, dès que l'on utilise la douchette. Comment "écoute r"
>> mon port usb , Si vous avez des pistes je suis preneur. D'avance merci
>> Pascal
> Bonjour,
> Est-ce qu'une piste ne consisterait pas à vérifier si le port USB n e
> serait pas en fait utilisé en émulation d'un port série ?
> Sur la question on trouve ça :
>http://www.cppfrance.com/forum/sujet-UTILISER-PORT-USB-COMME-PORT-SER...
> qui s'avère fort lisible. Cela étant le numéro de port ne sera pe ut-être
> pas le même chez toi.
> Une fois que tu as réussi à te connecter à ta douchette comme si elle
> était sur un port série tout bête, alors là on tombe dans un su jet
> beaucoup plus classique, la communication par port série, j'imagine q ue
> tu sauras te documenter dessus.
> On peut imaginer une solution simpliste qui consiste à juste détect er
> l'arrivée d'un caractère de la douchette, et à ce moment sélect ionner la
> base, et ensuite laisser faire le pilote fourni, qui émule le clavier .
> Mais si on fait ça j'appréhende un problème, c'est que le temps q u'on
> sélectionne la fenêtre plusieurs caractères ont déjà été transmis. On
> pourrait penser à passer la douchette une deuxième fois, mais les
> caractères transmis, en émulation clavier, ont pu provoquer des
> perturbations dans les autres applications.
> Donc de deux choses l'une, soit tu trouves une astuce pour contourner c e
> problème, soit tu trouves un moyen de désactiver le pilote qui ém ule le
> clavier, tu potasses la communication par port série, et tu écris
> toi-même la réception des caractères. Comme ça, comme tu sais o ù les
> envoyer, tu peux ouvrir Access en DDE, créer ton enregistrement en
> respectant les contraintes d'intégrité, ouvrir la fenêtre de cr éation
> qui va bien ...
> C'est vrai que c'est plus astreignant que d'utiliser l'émulation
> clavier, mais au moins tu maîtrises bien la chose. Est-ce que la doc de
> la douchette est bavarde ? Par exemple sur la possibilité d'ajouter d es
> caractères devant la chaîne reçue ?
Une fois que je ne suis plus en train d'écrire, ça me laisse les
neurones pour réfléchir :)
En fait, quand on ouvre un port série avec un programme, généraleme nt ça
le verrouille, donc on ne peut pas l'ouvrir avec un autre programme.
Donc, l'alternative ne se pose pas vraiment dans les termes que j'ai
indiqués.
C'est plutôt, ou le fournisseur de la douchette a anticipé le probl ème,
et explique quelque part dans la doc comment préciser l'application
destinataire des informations, ou ce n'est pas le cas et il faut
t'orienter vers l'autre solution, désactiver le pilote fourni, et écr ire
ton propre programme de réception.
Gloops a écrit, le 10/06/2011 21:40 :
> Pogo a écrit, le 10/06/2011 10:49 :
>> Bonjour,
>> J'ai un formulaire Access qui se rempli via un lecteur de code barre
>> (Code 39) . La douchette est connectée par le port USB. Pour une
>> meilleure automatisation, j'aurais besoin d'activer la fenêtre du
>> fichier access, dès que l'on utilise la douchette. Comment "écoute r"
>> mon port usb , Si vous avez des pistes je suis preneur. D'avance merci
>> Pascal
> Bonjour,
> Est-ce qu'une piste ne consisterait pas à vérifier si le port USB n e
> serait pas en fait utilisé en émulation d'un port série ?
> Sur la question on trouve ça :
>http://www.cppfrance.com/forum/sujet-UTILISER-PORT-USB-COMME-PORT-SER...
> qui s'avère fort lisible. Cela étant le numéro de port ne sera pe ut-être
> pas le même chez toi.
> Une fois que tu as réussi à te connecter à ta douchette comme si elle
> était sur un port série tout bête, alors là on tombe dans un su jet
> beaucoup plus classique, la communication par port série, j'imagine q ue
> tu sauras te documenter dessus.
> On peut imaginer une solution simpliste qui consiste à juste détect er
> l'arrivée d'un caractère de la douchette, et à ce moment sélect ionner la
> base, et ensuite laisser faire le pilote fourni, qui émule le clavier .
> Mais si on fait ça j'appréhende un problème, c'est que le temps q u'on
> sélectionne la fenêtre plusieurs caractères ont déjà été transmis. On
> pourrait penser à passer la douchette une deuxième fois, mais les
> caractères transmis, en émulation clavier, ont pu provoquer des
> perturbations dans les autres applications.
> Donc de deux choses l'une, soit tu trouves une astuce pour contourner c e
> problème, soit tu trouves un moyen de désactiver le pilote qui ém ule le
> clavier, tu potasses la communication par port série, et tu écris
> toi-même la réception des caractères. Comme ça, comme tu sais o ù les
> envoyer, tu peux ouvrir Access en DDE, créer ton enregistrement en
> respectant les contraintes d'intégrité, ouvrir la fenêtre de cr éation
> qui va bien ...
> C'est vrai que c'est plus astreignant que d'utiliser l'émulation
> clavier, mais au moins tu maîtrises bien la chose. Est-ce que la doc de
> la douchette est bavarde ? Par exemple sur la possibilité d'ajouter d es
> caractères devant la chaîne reçue ?
Une fois que je ne suis plus en train d'écrire, ça me laisse les
neurones pour réfléchir :)
En fait, quand on ouvre un port série avec un programme, généraleme nt ça
le verrouille, donc on ne peut pas l'ouvrir avec un autre programme.
Donc, l'alternative ne se pose pas vraiment dans les termes que j'ai
indiqués.
C'est plutôt, ou le fournisseur de la douchette a anticipé le probl ème,
et explique quelque part dans la doc comment préciser l'application
destinataire des informations, ou ce n'est pas le cas et il faut
t'orienter vers l'autre solution, désactiver le pilote fourni, et écr ire
ton propre programme de réception.
Gloops a écrit, le 10/06/2011 21:40 :
> Pogo a écrit, le 10/06/2011 10:49 :
>> Bonjour,
>> J'ai un formulaire Access qui se rempli via un lecteur de code barre
>> (Code 39) . La douchette est connectée par le port USB. Pour une
>> meilleure automatisation, j'aurais besoin d'activer la fenêtre du
>> fichier access, dès que l'on utilise la douchette. Comment "écoute r"
>> mon port usb , Si vous avez des pistes je suis preneur. D'avance merci
>> Pascal
> Bonjour,
> Est-ce qu'une piste ne consisterait pas à vérifier si le port USB n e
> serait pas en fait utilisé en émulation d'un port série ?
> Sur la question on trouve ça :
>http://www.cppfrance.com/forum/sujet-UTILISER-PORT-USB-COMME-PORT-SER...
> qui s'avère fort lisible. Cela étant le numéro de port ne sera pe ut-être
> pas le même chez toi.
> Une fois que tu as réussi à te connecter à ta douchette comme si elle
> était sur un port série tout bête, alors là on tombe dans un su jet
> beaucoup plus classique, la communication par port série, j'imagine q ue
> tu sauras te documenter dessus.
> On peut imaginer une solution simpliste qui consiste à juste détect er
> l'arrivée d'un caractère de la douchette, et à ce moment sélect ionner la
> base, et ensuite laisser faire le pilote fourni, qui émule le clavier .
> Mais si on fait ça j'appréhende un problème, c'est que le temps q u'on
> sélectionne la fenêtre plusieurs caractères ont déjà été transmis. On
> pourrait penser à passer la douchette une deuxième fois, mais les
> caractères transmis, en émulation clavier, ont pu provoquer des
> perturbations dans les autres applications.
> Donc de deux choses l'une, soit tu trouves une astuce pour contourner c e
> problème, soit tu trouves un moyen de désactiver le pilote qui ém ule le
> clavier, tu potasses la communication par port série, et tu écris
> toi-même la réception des caractères. Comme ça, comme tu sais o ù les
> envoyer, tu peux ouvrir Access en DDE, créer ton enregistrement en
> respectant les contraintes d'intégrité, ouvrir la fenêtre de cr éation
> qui va bien ...
> C'est vrai que c'est plus astreignant que d'utiliser l'émulation
> clavier, mais au moins tu maîtrises bien la chose. Est-ce que la doc de
> la douchette est bavarde ? Par exemple sur la possibilité d'ajouter d es
> caractères devant la chaîne reçue ?
Une fois que je ne suis plus en train d'écrire, ça me laisse les
neurones pour réfléchir :)
En fait, quand on ouvre un port série avec un programme, généraleme nt ça
le verrouille, donc on ne peut pas l'ouvrir avec un autre programme.
Donc, l'alternative ne se pose pas vraiment dans les termes que j'ai
indiqués.
C'est plutôt, ou le fournisseur de la douchette a anticipé le probl ème,
et explique quelque part dans la doc comment préciser l'application
destinataire des informations, ou ce n'est pas le cas et il faut
t'orienter vers l'autre solution, désactiver le pilote fourni, et écr ire
ton propre programme de réception.
Salut,
"Pogo"
[...]
Avec la douchette, il n'y a pas de pilote fourni, ni doc, c'est du
"plug and play!!!". J'ai du écrire la fonction qui permet de
transcrire les caractère renvoyés par le lecteur en code 39.
En effet, il y a surement moyen de gérer la connexion comme un port
com avec une inteface similaire à un rs232.
___________________
S'il n'y a pas de pilote, c'est qu'elle émule une simple saisie au cl aivier ;-)
et dans ce cas, oublie le rs232 et compagnie.
Tu dis avoir écris un fonction de "transcodage" ??
Pourquoi faire ? Le code 39 renvoie justement des caractères ASCII
sans besoin de transcoder quoi que ce soit.
C'est totalement équivalent à une saisie standard au clavier...
à tel point, que pour imprimer, il suffit d'utilise une "fonte" code3 9
comme tu pourras trouver sur mon site:
http://www.3stone.be/access/download.php?lng=fr&pga
Par contre, dire qu'il n'y a pas de doc pour la douchette, signifie
plutôt que tu l'as acheté chez un marchand de légumes ;-)
Car, ces douchettes "plug and pay" se paramètrent en lisant
des codes "spéciaux" pour les configurer.
Exemple:
- A la lecture, je fait suivre par un retour chariot, ou non ?
- Lors de la lecture, le code39 utilise le caractère "*" comme
caractère de début et de fin, par défaut...
mais je peux en définir un autre, lequel ? etc...
Donc, si l'on revient à ta question originale, une saisie clavier
NE PEUT PAS donner automatiquement le focus à ton application,
car sinon, comme t'adresser à Windows ??
Par contre, application démarrée, formulaire ouvert, il est très
simple de donner le focus à la zone de texte qui va bien...
Pour cela il faut passer par l'événement "sur touche appuyée"
du *formulaire* et y traiter la saisie pour, le cas échéant,
transmettre la "saisie" à la zone de texte sous-jacente.
Salut,
"Pogo"
[...]
Avec la douchette, il n'y a pas de pilote fourni, ni doc, c'est du
"plug and play!!!". J'ai du écrire la fonction qui permet de
transcrire les caractère renvoyés par le lecteur en code 39.
En effet, il y a surement moyen de gérer la connexion comme un port
com avec une inteface similaire à un rs232.
___________________
S'il n'y a pas de pilote, c'est qu'elle émule une simple saisie au cl aivier ;-)
et dans ce cas, oublie le rs232 et compagnie.
Tu dis avoir écris un fonction de "transcodage" ??
Pourquoi faire ? Le code 39 renvoie justement des caractères ASCII
sans besoin de transcoder quoi que ce soit.
C'est totalement équivalent à une saisie standard au clavier...
à tel point, que pour imprimer, il suffit d'utilise une "fonte" code3 9
comme tu pourras trouver sur mon site:
http://www.3stone.be/access/download.php?lng=fr&pg=61
Par contre, dire qu'il n'y a pas de doc pour la douchette, signifie
plutôt que tu l'as acheté chez un marchand de légumes ;-)
Car, ces douchettes "plug and pay" se paramètrent en lisant
des codes "spéciaux" pour les configurer.
Exemple:
- A la lecture, je fait suivre par un retour chariot, ou non ?
- Lors de la lecture, le code39 utilise le caractère "*" comme
caractère de début et de fin, par défaut...
mais je peux en définir un autre, lequel ? etc...
Donc, si l'on revient à ta question originale, une saisie clavier
NE PEUT PAS donner automatiquement le focus à ton application,
car sinon, comme t'adresser à Windows ??
Par contre, application démarrée, formulaire ouvert, il est très
simple de donner le focus à la zone de texte qui va bien...
Pour cela il faut passer par l'événement "sur touche appuyée"
du *formulaire* et y traiter la saisie pour, le cas échéant,
transmettre la "saisie" à la zone de texte sous-jacente.
Salut,
"Pogo"
[...]
Avec la douchette, il n'y a pas de pilote fourni, ni doc, c'est du
"plug and play!!!". J'ai du écrire la fonction qui permet de
transcrire les caractère renvoyés par le lecteur en code 39.
En effet, il y a surement moyen de gérer la connexion comme un port
com avec une inteface similaire à un rs232.
___________________
S'il n'y a pas de pilote, c'est qu'elle émule une simple saisie au cl aivier ;-)
et dans ce cas, oublie le rs232 et compagnie.
Tu dis avoir écris un fonction de "transcodage" ??
Pourquoi faire ? Le code 39 renvoie justement des caractères ASCII
sans besoin de transcoder quoi que ce soit.
C'est totalement équivalent à une saisie standard au clavier...
à tel point, que pour imprimer, il suffit d'utilise une "fonte" code3 9
comme tu pourras trouver sur mon site:
http://www.3stone.be/access/download.php?lng=fr&pga
Par contre, dire qu'il n'y a pas de doc pour la douchette, signifie
plutôt que tu l'as acheté chez un marchand de légumes ;-)
Car, ces douchettes "plug and pay" se paramètrent en lisant
des codes "spéciaux" pour les configurer.
Exemple:
- A la lecture, je fait suivre par un retour chariot, ou non ?
- Lors de la lecture, le code39 utilise le caractère "*" comme
caractère de début et de fin, par défaut...
mais je peux en définir un autre, lequel ? etc...
Donc, si l'on revient à ta question originale, une saisie clavier
NE PEUT PAS donner automatiquement le focus à ton application,
car sinon, comme t'adresser à Windows ??
Par contre, application démarrée, formulaire ouvert, il est très
simple de donner le focus à la zone de texte qui va bien...
Pour cela il faut passer par l'événement "sur touche appuyée"
du *formulaire* et y traiter la saisie pour, le cas échéant,
transmettre la "saisie" à la zone de texte sous-jacente.
Par contre, dire qu'il n'y a pas de doc pour la douchette, signifie
plutôt que tu l'as acheté chez un marchand de légumes ;-)
Car, ces douchettes "plug and pay" se paramètrent en lisant
des codes "spéciaux" pour les configurer.
Exemple:
- A la lecture, je fait suivre par un retour chariot, ou non ?
- Lors de la lecture, le code39 utilise le caractère "*" comme
caractère de début et de fin, par défaut...
mais je peux en définir un autre, lequel ? etc...
Donc, si l'on revient à ta question originale, une saisie clavier
NE PEUT PAS donner automatiquement le focus à ton application,
car sinon, comme t'adresser à Windows ??
Par contre, application démarrée, formulaire ouvert, il est très
simple de donner le focus à la zone de texte qui va bien...
Pour cela il faut passer par l'événement "sur touche appuyée"
du *formulaire* et y traiter la saisie pour, le cas échéant,
transmettre la "saisie" à la zone de texte sous-jacente.
USB
Later barcode readers began to use USB connectors rather than the keybo ard port, as this
became a more convenient hardware option. To retain the easy integratio n with existing
programs, a device driver called a "software wedge" could be used, to e mulate the
keyboard-impersonating behaviour of the old "keyboard wedge" hardware.
In many cases a choice of USB interface types (HID, CDC) are provided. Some have Powered USB.
Par contre, dire qu'il n'y a pas de doc pour la douchette, signifie
plutôt que tu l'as acheté chez un marchand de légumes ;-)
Car, ces douchettes "plug and pay" se paramètrent en lisant
des codes "spéciaux" pour les configurer.
Exemple:
- A la lecture, je fait suivre par un retour chariot, ou non ?
- Lors de la lecture, le code39 utilise le caractère "*" comme
caractère de début et de fin, par défaut...
mais je peux en définir un autre, lequel ? etc...
Donc, si l'on revient à ta question originale, une saisie clavier
NE PEUT PAS donner automatiquement le focus à ton application,
car sinon, comme t'adresser à Windows ??
Par contre, application démarrée, formulaire ouvert, il est très
simple de donner le focus à la zone de texte qui va bien...
Pour cela il faut passer par l'événement "sur touche appuyée"
du *formulaire* et y traiter la saisie pour, le cas échéant,
transmettre la "saisie" à la zone de texte sous-jacente.
USB
Later barcode readers began to use USB connectors rather than the keybo ard port, as this
became a more convenient hardware option. To retain the easy integratio n with existing
programs, a device driver called a "software wedge" could be used, to e mulate the
keyboard-impersonating behaviour of the old "keyboard wedge" hardware.
In many cases a choice of USB interface types (HID, CDC) are provided. Some have Powered USB.
Par contre, dire qu'il n'y a pas de doc pour la douchette, signifie
plutôt que tu l'as acheté chez un marchand de légumes ;-)
Car, ces douchettes "plug and pay" se paramètrent en lisant
des codes "spéciaux" pour les configurer.
Exemple:
- A la lecture, je fait suivre par un retour chariot, ou non ?
- Lors de la lecture, le code39 utilise le caractère "*" comme
caractère de début et de fin, par défaut...
mais je peux en définir un autre, lequel ? etc...
Donc, si l'on revient à ta question originale, une saisie clavier
NE PEUT PAS donner automatiquement le focus à ton application,
car sinon, comme t'adresser à Windows ??
Par contre, application démarrée, formulaire ouvert, il est très
simple de donner le focus à la zone de texte qui va bien...
Pour cela il faut passer par l'événement "sur touche appuyée"
du *formulaire* et y traiter la saisie pour, le cas échéant,
transmettre la "saisie" à la zone de texte sous-jacente.
USB
Later barcode readers began to use USB connectors rather than the keybo ard port, as this
became a more convenient hardware option. To retain the easy integratio n with existing
programs, a device driver called a "software wedge" could be used, to e mulate the
keyboard-impersonating behaviour of the old "keyboard wedge" hardware.
In many cases a choice of USB interface types (HID, CDC) are provided. Some have Powered USB.
Salut,
"Pogo"
[...]
Avec la douchette, il n'y a pas de pilote fourni, ni doc, c'est du
"plug and play!!!". J'ai du écrire la fonction qui permet de
transcrire les caractère renvoyés par le lecteur en code 39.
En effet, il y a surement moyen de gérer la connexion comme un port
com avec une inteface similaire à un rs232.
___________________
S'il n'y a pas de pilote, c'est qu'elle émule une simple saisie au clai vier ;-)
et dans ce cas, oublie le rs232 et compagnie.
Tu dis avoir écris un fonction de "transcodage" ??
Pourquoi faire ? Le code 39 renvoie justement des caractères ASCII
sans besoin de transcoder quoi que ce soit.
C'est totalement équivalent à une saisie standard au clavier...
à tel point, que pour imprimer, il suffit d'utilise une "fonte" code39
comme tu pourras trouver sur mon site:http://www.3stone.be/access/downloa d.php?lng=fr&pga
Par contre, dire qu'il n'y a pas de doc pour la douchette, signifie
plutôt que tu l'as acheté chez un marchand de légumes ;-)
Car, ces douchettes "plug and pay" se paramètrent en lisant
des codes "spéciaux" pour les configurer.
Exemple:
- A la lecture, je fait suivre par un retour chariot, ou non ?
- Lors de la lecture, le code39 utilise le caractère "*" comme
caractère de début et de fin, par défaut...
mais je peux en définir un autre, lequel ? etc...
Donc, si l'on revient à ta question originale, une saisie clavier
NE PEUT PAS donner automatiquement le focus à ton application,
car sinon, comme t'adresser à Windows ??
Par contre, application démarrée, formulaire ouvert, il est très
simple de donner le focus à la zone de texte qui va bien...
Pour cela il faut passer par l'événement "sur touche appuyée"
du *formulaire* et y traiter la saisie pour, le cas échéant,
transmettre la "saisie" à la zone de texte sous-jacente.
--
A+
Pierre (3stone) Access MVP
Perso:http://www.3stone.be/
MPFA:http://www.mpfa.info/ (infos générales)
Salut,
"Pogo"
[...]
Avec la douchette, il n'y a pas de pilote fourni, ni doc, c'est du
"plug and play!!!". J'ai du écrire la fonction qui permet de
transcrire les caractère renvoyés par le lecteur en code 39.
En effet, il y a surement moyen de gérer la connexion comme un port
com avec une inteface similaire à un rs232.
___________________
S'il n'y a pas de pilote, c'est qu'elle émule une simple saisie au clai vier ;-)
et dans ce cas, oublie le rs232 et compagnie.
Tu dis avoir écris un fonction de "transcodage" ??
Pourquoi faire ? Le code 39 renvoie justement des caractères ASCII
sans besoin de transcoder quoi que ce soit.
C'est totalement équivalent à une saisie standard au clavier...
à tel point, que pour imprimer, il suffit d'utilise une "fonte" code39
comme tu pourras trouver sur mon site:http://www.3stone.be/access/downloa d.php?lng=fr&pg=61
Par contre, dire qu'il n'y a pas de doc pour la douchette, signifie
plutôt que tu l'as acheté chez un marchand de légumes ;-)
Car, ces douchettes "plug and pay" se paramètrent en lisant
des codes "spéciaux" pour les configurer.
Exemple:
- A la lecture, je fait suivre par un retour chariot, ou non ?
- Lors de la lecture, le code39 utilise le caractère "*" comme
caractère de début et de fin, par défaut...
mais je peux en définir un autre, lequel ? etc...
Donc, si l'on revient à ta question originale, une saisie clavier
NE PEUT PAS donner automatiquement le focus à ton application,
car sinon, comme t'adresser à Windows ??
Par contre, application démarrée, formulaire ouvert, il est très
simple de donner le focus à la zone de texte qui va bien...
Pour cela il faut passer par l'événement "sur touche appuyée"
du *formulaire* et y traiter la saisie pour, le cas échéant,
transmettre la "saisie" à la zone de texte sous-jacente.
--
A+
Pierre (3stone) Access MVP
Perso:http://www.3stone.be/
MPFA:http://www.mpfa.info/ (infos générales)
Salut,
"Pogo"
[...]
Avec la douchette, il n'y a pas de pilote fourni, ni doc, c'est du
"plug and play!!!". J'ai du écrire la fonction qui permet de
transcrire les caractère renvoyés par le lecteur en code 39.
En effet, il y a surement moyen de gérer la connexion comme un port
com avec une inteface similaire à un rs232.
___________________
S'il n'y a pas de pilote, c'est qu'elle émule une simple saisie au clai vier ;-)
et dans ce cas, oublie le rs232 et compagnie.
Tu dis avoir écris un fonction de "transcodage" ??
Pourquoi faire ? Le code 39 renvoie justement des caractères ASCII
sans besoin de transcoder quoi que ce soit.
C'est totalement équivalent à une saisie standard au clavier...
à tel point, que pour imprimer, il suffit d'utilise une "fonte" code39
comme tu pourras trouver sur mon site:http://www.3stone.be/access/downloa d.php?lng=fr&pga
Par contre, dire qu'il n'y a pas de doc pour la douchette, signifie
plutôt que tu l'as acheté chez un marchand de légumes ;-)
Car, ces douchettes "plug and pay" se paramètrent en lisant
des codes "spéciaux" pour les configurer.
Exemple:
- A la lecture, je fait suivre par un retour chariot, ou non ?
- Lors de la lecture, le code39 utilise le caractère "*" comme
caractère de début et de fin, par défaut...
mais je peux en définir un autre, lequel ? etc...
Donc, si l'on revient à ta question originale, une saisie clavier
NE PEUT PAS donner automatiquement le focus à ton application,
car sinon, comme t'adresser à Windows ??
Par contre, application démarrée, formulaire ouvert, il est très
simple de donner le focus à la zone de texte qui va bien...
Pour cela il faut passer par l'événement "sur touche appuyée"
du *formulaire* et y traiter la saisie pour, le cas échéant,
transmettre la "saisie" à la zone de texte sous-jacente.
--
A+
Pierre (3stone) Access MVP
Perso:http://www.3stone.be/
MPFA:http://www.mpfa.info/ (infos générales)
On 11 juin, 19:17, "3stone" wrote:Salut,
"Pogo"
[...]
Avec la douchette, il n'y a pas de pilote fourni, ni doc, c'est du
"plug and play!!!". J'ai du écrire la fonction qui permet de
transcrire les caractère renvoyés par le lecteur en code 39.
En effet, il y a surement moyen de gérer la connexion comme un port
com avec une inteface similaire à un rs232.
___________________
S'il n'y a pas de pilote, c'est qu'elle émule une simple saisie au c laivier ;-)
et dans ce cas, oublie le rs232 et compagnie.
Tu dis avoir écris un fonction de "transcodage" ??
Pourquoi faire ? Le code 39 renvoie justement des caractères ASCII
sans besoin de transcoder quoi que ce soit.
C'est totalement équivalent à une saisie standard au clavier...
à tel point, que pour imprimer, il suffit d'utilise une "fonte" code 39
comme tu pourras trouver sur mon site:http://www.3stone.be/access/down load.php?lng=fr&pga
Par contre, dire qu'il n'y a pas de doc pour la douchette, signifie
plutôt que tu l'as acheté chez un marchand de légumes ;-)
Car, ces douchettes "plug and pay" se paramètrent en lisant
des codes "spéciaux" pour les configurer.
Exemple:
- A la lecture, je fait suivre par un retour chariot, ou non ?
- Lors de la lecture, le code39 utilise le caractère "*" comme
caractère de début et de fin, par défaut...
mais je peux en définir un autre, lequel ? etc...
Donc, si l'on revient à ta question originale, une saisie clavier
NE PEUT PAS donner automatiquement le focus à ton application,
car sinon, comme t'adresser à Windows ??
Par contre, application démarrée, formulaire ouvert, il est très
simple de donner le focus à la zone de texte qui va bien...
Pour cela il faut passer par l'événement "sur touche appuyée"
du *formulaire* et y traiter la saisie pour, le cas échéant,
transmettre la "saisie" à la zone de texte sous-jacente.
--
A+
Pierre (3stone) Access MVP
Perso:http://www.3stone.be/
MPFA:http://www.mpfa.info/ (infos générales)
Bonjour,
les caracteres renvoyés par la douchette ne sont pas lisibles, j'ai d u
les convertir en binaire pour ensuite les recoder en code 39.
Un
changement de fonte ne changerait pas grand chose car les caractères
renvoyés me permet de faire une recherche dans un recordset afin de m e
fournir des données complémentaires.
Concernant la question initiale:
Il y a plusieurs applications différentes qui sont ouvertes sur le
poste où est branché la douchette. Quand la douchette est utilisé e, la
fenêtre active n'est pas forcément celle qui correspond à
l'application qui doit récupérer les données scannées. J'ai don c
besoin de détecter l'utilisation de la douchette pour activer ou
ouvrir l'application correspondante
Voila, je ne sais pas si j'ai été clair...
On 11 juin, 19:17, "3stone"<sw...@home.be> wrote:
Salut,
"Pogo"
[...]
Avec la douchette, il n'y a pas de pilote fourni, ni doc, c'est du
"plug and play!!!". J'ai du écrire la fonction qui permet de
transcrire les caractère renvoyés par le lecteur en code 39.
En effet, il y a surement moyen de gérer la connexion comme un port
com avec une inteface similaire à un rs232.
___________________
S'il n'y a pas de pilote, c'est qu'elle émule une simple saisie au c laivier ;-)
et dans ce cas, oublie le rs232 et compagnie.
Tu dis avoir écris un fonction de "transcodage" ??
Pourquoi faire ? Le code 39 renvoie justement des caractères ASCII
sans besoin de transcoder quoi que ce soit.
C'est totalement équivalent à une saisie standard au clavier...
à tel point, que pour imprimer, il suffit d'utilise une "fonte" code 39
comme tu pourras trouver sur mon site:http://www.3stone.be/access/down load.php?lng=fr&pg=61
Par contre, dire qu'il n'y a pas de doc pour la douchette, signifie
plutôt que tu l'as acheté chez un marchand de légumes ;-)
Car, ces douchettes "plug and pay" se paramètrent en lisant
des codes "spéciaux" pour les configurer.
Exemple:
- A la lecture, je fait suivre par un retour chariot, ou non ?
- Lors de la lecture, le code39 utilise le caractère "*" comme
caractère de début et de fin, par défaut...
mais je peux en définir un autre, lequel ? etc...
Donc, si l'on revient à ta question originale, une saisie clavier
NE PEUT PAS donner automatiquement le focus à ton application,
car sinon, comme t'adresser à Windows ??
Par contre, application démarrée, formulaire ouvert, il est très
simple de donner le focus à la zone de texte qui va bien...
Pour cela il faut passer par l'événement "sur touche appuyée"
du *formulaire* et y traiter la saisie pour, le cas échéant,
transmettre la "saisie" à la zone de texte sous-jacente.
--
A+
Pierre (3stone) Access MVP
Perso:http://www.3stone.be/
MPFA:http://www.mpfa.info/ (infos générales)
Bonjour,
les caracteres renvoyés par la douchette ne sont pas lisibles, j'ai d u
les convertir en binaire pour ensuite les recoder en code 39.
Un
changement de fonte ne changerait pas grand chose car les caractères
renvoyés me permet de faire une recherche dans un recordset afin de m e
fournir des données complémentaires.
Concernant la question initiale:
Il y a plusieurs applications différentes qui sont ouvertes sur le
poste où est branché la douchette. Quand la douchette est utilisé e, la
fenêtre active n'est pas forcément celle qui correspond à
l'application qui doit récupérer les données scannées. J'ai don c
besoin de détecter l'utilisation de la douchette pour activer ou
ouvrir l'application correspondante
Voila, je ne sais pas si j'ai été clair...
On 11 juin, 19:17, "3stone" wrote:Salut,
"Pogo"
[...]
Avec la douchette, il n'y a pas de pilote fourni, ni doc, c'est du
"plug and play!!!". J'ai du écrire la fonction qui permet de
transcrire les caractère renvoyés par le lecteur en code 39.
En effet, il y a surement moyen de gérer la connexion comme un port
com avec une inteface similaire à un rs232.
___________________
S'il n'y a pas de pilote, c'est qu'elle émule une simple saisie au c laivier ;-)
et dans ce cas, oublie le rs232 et compagnie.
Tu dis avoir écris un fonction de "transcodage" ??
Pourquoi faire ? Le code 39 renvoie justement des caractères ASCII
sans besoin de transcoder quoi que ce soit.
C'est totalement équivalent à une saisie standard au clavier...
à tel point, que pour imprimer, il suffit d'utilise une "fonte" code 39
comme tu pourras trouver sur mon site:http://www.3stone.be/access/down load.php?lng=fr&pga
Par contre, dire qu'il n'y a pas de doc pour la douchette, signifie
plutôt que tu l'as acheté chez un marchand de légumes ;-)
Car, ces douchettes "plug and pay" se paramètrent en lisant
des codes "spéciaux" pour les configurer.
Exemple:
- A la lecture, je fait suivre par un retour chariot, ou non ?
- Lors de la lecture, le code39 utilise le caractère "*" comme
caractère de début et de fin, par défaut...
mais je peux en définir un autre, lequel ? etc...
Donc, si l'on revient à ta question originale, une saisie clavier
NE PEUT PAS donner automatiquement le focus à ton application,
car sinon, comme t'adresser à Windows ??
Par contre, application démarrée, formulaire ouvert, il est très
simple de donner le focus à la zone de texte qui va bien...
Pour cela il faut passer par l'événement "sur touche appuyée"
du *formulaire* et y traiter la saisie pour, le cas échéant,
transmettre la "saisie" à la zone de texte sous-jacente.
--
A+
Pierre (3stone) Access MVP
Perso:http://www.3stone.be/
MPFA:http://www.mpfa.info/ (infos générales)
Bonjour,
les caracteres renvoyés par la douchette ne sont pas lisibles, j'ai d u
les convertir en binaire pour ensuite les recoder en code 39.
Un
changement de fonte ne changerait pas grand chose car les caractères
renvoyés me permet de faire une recherche dans un recordset afin de m e
fournir des données complémentaires.
Concernant la question initiale:
Il y a plusieurs applications différentes qui sont ouvertes sur le
poste où est branché la douchette. Quand la douchette est utilisé e, la
fenêtre active n'est pas forcément celle qui correspond à
l'application qui doit récupérer les données scannées. J'ai don c
besoin de détecter l'utilisation de la douchette pour activer ou
ouvrir l'application correspondante
Voila, je ne sais pas si j'ai été clair...