J’ai trouvé une solution qui marche pour les douchettes à CR/LF (et les autres) mais je ne sais pas si elle est très élégante (il serait plus souple et plus sûr que la modif soit actionnée sur un paramètre de la fonction ajax_autocompleter) et si elle n’a pas d’effet secondaire ailleurs.
En fait il suffit de faire en sorte que le CR/LF (touche ENTER) soit ignoré.
En V12.0.3, j’ai fais ça dans /core/lib/ajax.lib.php dans function ajax_autocompleter
A partir de la ligne 68, je remplace :
$("input#search_'.$htmlname.'").keydown(function(e) {
if (e.keyCode != 9) /* If not "Tab" key */
{
console.log("Clear id previously selected for field '.$htmlname.'");
$("#'.$htmlname.'").val("");
}
});
Par le code :
$("input#search_'.$htmlname.'").keydown(function(e) {
if (e.keyCode != 9) /* If not "Tab" key */
{
if (e.keyCode == 13) {return false;} /*disable "ENTER" key Zuiko*/
console.log("Clear id previously selected for field '.$htmlname.'");
$("#'.$htmlname.'").val("");
}
});
Bien sûr j’ai gardé :les modifications du fichier /core/class/html.form.class.php :
Le seul test que j’ai fait c’est avec la donnée du module Produits
Attendre que vous ayez appuyé sur une touche avant de charger le contenu de la liste déroulante des produits
positionnée à OUI (3 caractères)
Dans ce cas les performances sont excellentes, l’affichage est instantané, qu’on fasse la sélection du produit à la main ou à la douchette. Je n’ai pas vu d’inconvénient, pour ce champ, d’ignorer la touche ENTER.
J’ai complété mon test en faisant varier cette donnée :
pour NON cela ne marche pas moins bien mais évidemment avec 10K produits les temps de latence sont insupportables.
à OUI 1 2 ou 3 caractères la réactivité est au top par contre il ne faut pas limiter le nombre de produit si non il risque de ne pas être trouvé mais ça c’est normal
Il faudrait tester dans d’autres contextes où cet ajax est employé…
Si je fais ça dans le code que je propose (ignorer le caractère 13), c’est bien parce que la plupart des douchettes finissent leur saisie par un retour à la ligne (autrement dit : touche ENTER ou CR/LF ou caractère 13 du clavier).
Sur une de celles que j’utilise c’est codé en dur donc cela ne peut pas être changé et de toute façon, dans la plupart des usages ce retour à la ligne est un gain de temps dans la saisie.
Voir le Pull Request #15704 dans la version en développement ou le #15694 sur la V12.0.3
Si le caractère 13 est accepté par la saisie, il arrive trop tôt par rapport à la sélection du produit dans la liste via le javascrpt ajax et efface le champ.
Je partage mon retour sur la douchette pour Takepos.
J’ai acheté une douchette low cost afin de tester le comportement de TakePos avec douchette (j’ai dolibarr v13.0.2). J’ai été étonnement surprise du bon fonctionnent des deux !
Une fois le curseur dans « recherche », on scanne le produit, puis takepos le trouve, puis il l’ajoute automatiquement au ticket, sans clic supplémentaire. GENIAL ! Entre l’opération de scan et l’ajout du produit à la note, il faut compter 3 à 4 sec maxi.
Cela fonctionne également pour des cartes de fidélité client (si vous avez attribué des code-barres à vos clients bien entendu).
Pas mal du tout pour un premier test. Je vous ferai des retours dans l’opérationnel au quotidien.
La seule manip que j’ai effectué avant utilisation, est le scan du code-barre pour la langue française. C’est tout.
Simple et efficace ! Je recommande…
Au top, mille mercis pour le code !
Je ne savais pas que vous l’aviez intégré d’office, c’est extra
Je mets tout ça en situation réelle mardi prochain au magasin !
Et bien qu’en j’expérimente du code qui fonctionne, je le dépose sur Github, il est revu, discuté et si approuvé, intégré. C’est ça la magie de l’open source
