Newsgroup: it.comp.lang.visual-basic
Titolo: [?] Lettore cod.barre in emulazione di tastiera e compilazione campi

Devo realizzare una particolare applicazione utilizzando un lettore di
codice a barre in emulazione di tastiera.
Siccome devo anche consentire l'input da tastiera (per esempio per merce
sprovvista di codice a barre o in una codifica non interpretata dal lettore
stesso), mi stavo ponendo il problema di come abbandonare il textbox
corrente e destinatario dell'informazione.
Vorrei cioè che il textbox corrente venga automaticamente abbandonato (con
un vbTab implicito suppongo) quando l'acquisizione del codice avviene da
lettore, ma solo esplicitamente "da tastiera" (battendo il tasto Tab) quando
il codice viene digitato.
Devo quindi escludere l'evento Change in quanto questo verrebbe attivato
quando digito ogni carattere (tranne intercettare con KeyDown) e mi stavo
chiedendo se i lettori in emulazione di tastiera (non ne ho sottomano per
provare, nè so che lettore verrà adottato) hanno la possibilità di spedire,
in coda al codice letto, anche un vbTab o, comunque, un crt speciale da
interpretarsi come "fine stringa". Grazie per ogni informazione.

 il textbox corrente e destinatario dell'informazione.
Di solito i lettori barcode in emulazione tastiera possono essere
configurati per aggiungere o meno dopo il valore letto un invio oppure un
tab (per il secondo non ci giurerei per il primo il mio lettore di codici a
barre lo fa di sicuro!)

 il textbox corrente e destinatario dell'informazione.
questo lo avevi letto?
http://makeashorterlink.com/?S130320F7
-- 
Salutoni
Sergio
per rispondere... togli il group dall'indirizzo

 
http://makeashorterlink.com/?S130320F7
Forse sì, in ogni caso l'ho letto ora. Anche qui si parla di "... lo puoi
impostare da pistola..."
Il mio problema è sapere se il lettore, con certezza, mi rende anche un fine
stringa, qualunque esso sia.
Se sì non ho problemi, se no (o nel dubbio, non sapendo quale sarà) devo
implementare un altro metodo.
Grazie, anche a Lord.


Normalmente tutti i lettori di medio-alta gamma (parlo di questi perchè sono
quelli che utilizzo quotidianamente), hanno la possibilità di essere
programmati, aggiungendo un terminatore o un header. Imho anche quelli di
bassa gamma.
Per caso conosci già il modello di lettore che utilizzerai?
ciaociao

 un fine stringa, qualunque esso sia.
Va impostato afaik nel lettore in base all'utilizzo! Al limite gliene
includi uno adatto nel prezzo del software! ;-)

 devo implementare un altro metodo.
Immagino sia una scelta che tu subisci, ma, se hai voce in capitolo, insisti
per usare un lettore seriale. Costa uguale, ma quanto a comodità di sviluppo
software, passi dalla notte al giorno.
Ciao
Alberto

[Albe V°] scrisse:
(snip)
squillino le trombe...
rullino i tamburi...
signore e signori, eccovi il vincitore della prima giornata del campionato
del lido degli estensi.
si, lo so, è clamorosamente ot, ma non credo che succederà tante altre
volte...



aahh, su questo non si discute! quoto tutto. ;-)
ciaociao

[Albe V° = 
circa_vac...@hotmail.com
 in
c4ra3l$2lp9q2$
1...@ID-222113.news.uni-berlin.de
] ha scritto:

Ho voce in capitolo e potrei persino pretendere, ma non ho capito se io devo
sviluppare software...
L'ho fatto (via MsComm) per i lettori con memoria (si caricano, leggendo in
giro per il mondo, e poi si "scaricano" mettendo la penna nel "calamaio",
fisicamente collegato alla seriale), ma l'unica volta che ho provicchiato un
lettore in emulazione di tastiera, l'ho agganciato e questo andava. Mi
aspetterei di fare altrettanto...
Albe, se ti riferisci a modalità diverse e/o potenzialità da sfruttare, ok,
viceversa non ho davvero capito a quale sviluppo ti riferisca. Puoi darmi
qualche chiarimento? Grazie.

 riferisca. Puoi darmi qualche chiarimento? Grazie.
No, il funzionamento e le cose che fa sono le stesse, però da una parte c'è
la form, e dall'altra c'è la seriale. Due cose indipendenti, sincrone il
giusto, senza la minima possibilità di interferenza.
Focus, Change, Keypress, tasti di qua, codice di là, tutto facile.
Per chi sviluppa. E pensavo tu dovessi sviluppare il codice VB che gestisce
'sto sw, per cui...
Ciao
Alberto

 volte...
E se fosse l'inizio di una lunga, lunga serie?
http://www.fabsoft.it/leganavale/
Ciao
Alberto

[Albe V° = 
circa_vac...@hotmail.com
 in
c4rdjn$2jpdjo$
1...@ID-222113.news.uni-berlin.de
] ha scritto:

Boh!!!
Ancora non ho capito: Io devo scrivere un software in VB per l'acquisizione
di dati anche da lettore ottico in emulazione di tastiera. Per quel che ne
sapevo (fermo restando la disponibilità del terminatore da parte del
lettore), io non doveri fare _niente_ di diverso da quello che farei (e
farò) per far funzionare un banalissimo form che presuma l'uso della sola
tastiera...

 banalissimo form che presuma l'uso della sola tastiera...
Se c'è un solo textbox o un solo controllo che può 'beccarsi' i keypress,
hai ragione tu.
Se ne esistono anche solo due (anche un commandbutton ruba i tasti
premuti...), è una cosa da gestire.
Ricorda: l'operatore usa la tastiera guardando il monitor, e il lettore
guardando il prodotto...
Ciao
Alberto

 un fine stringa, qualunque esso sia.
Credo di si. Io ho lavorato con lettoridi codice a barre e ti posso
assicurare che anche un lettore da 70 ? può essere impostato per inviare
segnali di fine stringa.
bye
-- 
Esistono 10 tipi di persone: chi conosce il binario e chi no.
Gestione Ottica - Gestionale per Ottici e Programmi Gratuiti su:
http://www.nicolaottomano.it


Beh, visto il problema oggetto di questo 3d, non sembrerebbe proprio così
banale.... :-P
ciaociao

[Marg = 
circa...@inwind.it
 in
c4rg6n$2lba9p$
1...@ID-193795.news.uni-berlin.de
] ha scritto:

Rispondo qui solo perchè quoto tutto...
Se il lettore, in coda al codice, invia un vbTab (o anche un vbCrLf, che io
emulo come vbTab), allora non devo fare niente. Se no, lo so, devo fare
tutto. Ma, ripeto, quella volta che ho provato un lettore un emulazione di
tastiera ciò avveniva, quindi ... ancora non capisco. Sarà che è lunedì e/o
che la mia testa (e il mio braccio) sta ancora sulle 15 carpette (fuori
misura, <35 cm, e meno di 1kg, che però tiravano un tot e mi sono fatto "al
braz mansol", è sempre così in primavera) di ieri, ma ho la sensazione che
stiamo menando il can per l'aia...
La domanda è sempre quella: un lettore di barcode in em.tastiera rende un
crt di fine stringa?

 che io emulo come vbTab), allora non devo fare niente.
sei sicuro che l'operatore abbia il focus sul textbox giusto, quando opera
con la pistola di paperinik?
direi che il problema č tutto lě, perchč pare che le pistole schiaccino
l'invio, quanto meno, quando hanno finito di lavorare.


 rende un crt di fine stringa?
Sì
ciaociao

 schiaccino l'invio, quanto meno, quando hanno finito di lavorare.
Per quel che mi ricordo, no, almeno non è necessario. Sciacciare un tasto
dopo un lettura lo troverei, quantomeno, poco operativo, essendo un tasto in
più e, a mio modo di vedere, sufficiente per non proporre mai quel lettore
ad alcuno.
Il lettore dovrebbe mandare quanto letto (meglio se seguito da un "fine
stringa") dopo ogni lettura, qualunque cosa (codice, qtà a barre, etc.)
abbia letto, sempre che sia stato letto.
Che poi l'operatore legga prima la quantità (ove prevista in cod.barre) e
poi il codice quando la sequenza operativa è al contrario, beh, sono
faccende sue, anche quando la qtà possa essere intesa come codice e il
codice come qtà.

 Sì
Bene... Ovviamente manderò a te il tutto se il lettore (quale? non lo so!)
non lo dovesse fare.
Praticamente te lo sei comprato... :-P ;-)

 rende un crt di fine stringa?
Inizio stringa, fine stringa, può anche verificare i checksum direttamente
prima di inviarti il codice, può limitare il numero di caratteri che
compongono il codice, può anche restituire un codice identificativo del
lettore per distinguerlo da altri...
Se cerci doc, ricorda che la modalità trasmissiva (PS2, 232, 422, 485, TTL,
VT, ecc...), è solo un pezzettino di elettronica terminale e generalmente
sostituibile sulla stessa testa. Le funzionalità disponibili sono le stesse
per tutti.
Per quanto riguarda il cane menato per l'aia, il mio era solo un consiglio
en-passant, in quanto credevo che il link postato da Sergio fosse
sufficiente a rispondere al tuo quesito.
Ciao
Alberto

 Praticamente te lo sei comprato... :-P ;-)
Ok, se funge anche in rs232 mi fai pure un favore! :-P
ciaociao

 identificativo del lettore per distinguerlo da altri...
Dimenticavo: se lavora in emulazione tastiera, comunica SOLO emulando la
tastiera, per cui i crt di inizio e fine sono in realtà dei tasti.
Cioè, non puoi chiedere che ti invii CHR(3), ma che ti simuli un Tab, un
Invio, uno spazio, ecc...
Se comunica in seriale, invece, puoi impostare qualunque Ascii come inizio o
terminatore.
Ciao
Alberto

 proporre mai quel lettore ad alcuno.
scusa lupo, forse volendo fare lo spiritoso, mi sono espresso male.
intendevo dire che i lettori di codice a barre in emulazione tastiera, da
quanto ho visto, inviano un carattere "invio" in coda a quanto leggono.
questo intendevo quando ho scritto "pare che le pistole schiaccino l'invio",
non che dovesse farlo l'operatore.


 pistole schiaccino l'invio", non che dovesse farlo l'operatore.
Ahhhh, ok. (puff-pant) ;-)

 inizio o terminatore.
Release (forse) 6.0.8000 ;-)

 pistole schiaccino l'invio", non che dovesse farlo l'operatore.
Lo fanno _solamente_ se sono state configurate per farlo! ;-)

 Sì
NO! o meglio non sempre! Dipende da come lo configuri! L'affermazione "Un
lettore Barcode in emulazione tastiere rende SEMPRE un invio a fine stringa
letta" è assolutamente falsa!


Mi pareva OVVIO, dato che l'ho ripetuto in più di un post di questo 3d......
;-)
ma siccome Lupo voleva stringere e ha concluso con una domanda *secca*, ho
dato una risposta *secca*!
ciaociao

[Marg = 
circa...@inwind.it
 in
c4tp5c$2mf2ov$
1...@ID-193795.news.uni-berlin.de
] ha scritto:

Ma voi mi volete male! :o)
Comunque io, il crt di fine stringa, l'ho messo fra i prerequisiti. Ciapalè!
PS: Ora la domanda potrebbe essere "un lettore di barcode in em.tastiera,
opportunamente configurato, rende un crt di fine stringa?"
PS2: In tutta onestà non riesco a concepire come gestire un lettore che non
renda un fine stringa... Sarebbe come concepire un form dove il passaggio da
un campo all'altro non avviene con un tasto particolare esplicitamente
premuto dall'operatore, per esempio contando i crt previsti per ogni campo,
ovviamente in numero fisso e obbligato... 'na ciofeca.

 obbligato... 'na ciofeca.
Volendo fare pura accademia...
Dal link che ti aveva dato Sergio, vedrai come una delle cose più comode,
coi lettori in emulazione tastiera, è il cronometraggio della velocità di
battitura. Nessun umano raggiunge mai i tempi del lettore. Per cui, da
questo riesci a capire quando il lettore ha finito di inviare la sua
sequenza.
Ciao
Alberto

 finito di inviare la sua sequenza.
Sì, ho letto con attenzione e la cosa è furba, ma non credo che sia ...
obbligata. Almeno lo spero.

 che non renda un fine stringa... Sarebbe come concepire un form dove
Ad esempio in caso di codici a lunghezza fissa! Oppure quando si vuole che
per forza l'operatore confermi il dato inserito! ;-)

 obbligato... 'na ciofeca.
...io non riesco a concepire un lettore in emulazione tastiera..... :-PPP
ciaociao

 ...io non riesco a concepire un lettore in emulazione tastiera.....
La penso anch'io così (tant'è che il mio applicativo prevede solo quello con
memoria)
Comunque, così lo vogliono...
Immagino che, proprio perchè in em.di tastiera, ci sarà un filo che limita
la distanza fra il PC e il punto di lettura. Pensa che devono leggere
bancali di libri e, quindi, se li dovranno appropinquare quanto basta,
leggerli e metterli nel punto di distribuzione, già organizzati in pile.
Insomma, li muovono due volte...

 limita la distanza fra il PC e il punto di lettura.
Lupo, ti ripeto una cosa che forse ti sfugge:
Il lettore è composto di due parti:
- una testa che legge, elabora, e prepara la stringa. E questa può essere
Laser, CCD, e altro che non ricordo.
- un modulo di comunicazione, spesso intercambiabile sulla stessa testa.
Questo ultimo modulo, può essere un cavetto PS2, un cavetto RS232, o una
antennina wireless, che comunica con una basetta fissa, che a sua volta può
avere un cavetto PS2, un cavetto RS232, ecc...
Quindi, puoi avere un lettore in emulazione tastiera ma con trasmissione
radio.
Senza spendere cifre assurde, fino a 15mt non ci sono problemi di copertura,
bastano le antennine della basetta.
Anche questo deve far riflettere sulla 'sfigosità' dei lettori in emulazione
tastiera. Se si apre una finestrella di errore perchè manca carta nella
stampante, questa finestrella si becca le letture, e magari l'operatore se
ne accorge a fine giornata. Se l'operatore gioca a campo minato, e quando ha
finito lascia il fuoco sulla barra 'Avvio' (cosa comunissima), questa si
becca le letture anche se la tua app *sembra* in primo piano. Ometto le
sfighe legate al focus dei textbox, perchè sono ovvie.
I lettori in emulazione tastiera servono per adeguare software vecchi, nati
per operatori digitanti, senza doverli modificare.
Quando si fa un sw nuovo, esistono soluzioni cento volte più comode, come ad
esempio i lettori su seriale.
Ciao
Alberto

 copertura, bastano le antennine della basetta.
Buono a sapersi. Grazie.