Newsgroup: it.comp.lang.visual-basic
Titolo: sistema si mette in ascolto

Ciao gente,
premetto che l'appl. è stata fatta in vb6
L'applicazione è mdi con un form principale modello Word.
Voglio che l'applicazione, all'evento causato da una penna di codici a 
barre usb apra un form child .
Chi mi suggerisce come posso mettere in ascolto l'applicazione e fare in 
modo che apra il formchild non appena arriva lettura del codice a barre ?
thank

nnrp-beta.newsland.it
, martedì alle 17.00.31, ha estratto dai neuroni:

Se la penna è in emulazione di seriale, ossia comunica come se fosse 
connessa ad una porta seriale, è una cosa banale, perchè c'è l'evento 
OnComm che fa tutto lui.
Se invece simula una tastiera...
Beh, puoi inventare qualche accrocchio, ma resterà sempre una povera 
applicazione (non che stia dicendo niente di nuovo).
Se comunica con altri metodi, ad esempio con OCX proprietari del 
produttore, presumo esista un evento simile ad OnComm, che puoi 
gestire.
Ciao
Alberto
-- 
A questo punto hanno trovato un muro,
un muro duro, molto molto duro,
che siamo noi.


sub Text1_Change (con tutti gli accorgimenti del caso, come la lunghezza del 
codice, in modo da evitare le visualizzazioni non desiderabili) e se non 
vuoi fare vedere il codice rendi la text invisibile.
E non credo che per questo possa definirsi una povera applicazione....sempre 
evento è!
Umbe 

Nel suo scritto precedente, Umbe ha sostenuto :

Già.
L'evento di un controllo che potrebbe non avere il fuoco, su cui 
l'utente potrebbe scrivere a mano, che potrebbe appartenere al form 
figlio e quindi in sua assenza non esistere neppure...
Allora, a scanso di equivoci:
I lettori di barcode/tag (a penna o scanner che siano), hanno due 
funzioni:
1) 'automatizzare' una vecchia applicazione nata per la tastiera, per 
agevolare gli operatori
2) fare da input per applicazioni disegnate espressamente per usare i 
barcode.
Nel caso 1, e solo nel caso 1, si utilizzano i lettori in emulazione di 
tastiera.
Nel caso 2, si utilizzano lettori seriali o con altre forme di input di 
background.
Usare un lettore in emulazione di tastiera, su applicazioni 
espressamente disegnate per lavorare con bar-code, è una mostruosità.
Certo, chi si avvicina per la prima volta a queste cose, viene 
invogliato dalla apparente semplicità di dialogo con questi strumenti. 
Ma è solo apparente, in realtà ci si complica la vita, e parecchio.


 apparente, in realtà ci si complica la vita, e parecchio.
Porta pazienza Albe, ma non sono completamente d'accordo. Dipende dai punti 
di vista.
Dal punto di vista dello sviluppatore credo che le cose siano un po' 
diverse.
Se ho creato un' applicazione per usare lettori barcode (caso 2) tocca a me 
(sviluppatore) gestire il tipo di barcode stesso.
Se lo voglio seriale, gestiro' il seriale, se voglio l'emulatore, gestiro' 
l'emulatore.
Il tuo discorso è valido se scrivo una applicazione che gestice il seriale 
(e magari lo scrivo pure nelle specifiche del mio gestionale) ma l'ufficio 
acquisti dell' azienda dove gira il mio gestionale per risparmiare soldi(o 
per altri motivi) si compra l'emulatore perchè il fornitore hardware dice 
che è lo stesso....ecco qui pero' il programmatore non c'entra più.
Sono d'accordo con te se mi dici che il seriale è più flessibile (per lo 
sviluppatore) questo si', ma dire che è mostruoso usare l'emulatore mi 
sembra un po' esagerato.
Umbe

 un po' esagerato.
Grossomodo, è come dire che per accedere ad un db di Access si debba 
usare OleAutomation, avviare una istanza di Access, e poi eseguire le 
query con scansioni nelle finestre di Access stesso attraverso l'object 
model.
Si può fare.
Funziona.
Ma tu non lo definiresti 'mostruoso', nel senso di essersi andati a 
creare una immane complicazione inutile?


 una immane complicazione inutile?
Dai, non esagerare...sono cose diverse.
Tornando al discorso, sono due approcci diversi e come tali vanno gestiti.
Tutto qui.
Umbe

 applicazione, sarebbe bastato impedire che la form stessa lo perda
perdesse...pardon!
Umbe 

 scomodare dei timer.
Ah beh beh, se il reparto acquisti non è in grado di conoscere la
differenza tra un lettore barcode seriale e uno in emulazione di tastiera,
è anche facile che consideri conveniente utilizzare un pc per far girare
una e una sola applicazione...
-- 
Salutoni
Sergio
Per rispondere... togli il group dall'indirizzo
Se i tempi non chiedono la tua parte migliore, inventa altri tempi. 
(Baolian, libro II, vv. 16-17)
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Tornando al discorso, sono due approcci diversi e come tali vanno gestiti.
Certo che sono approcci diversi.
E, ripeto, in entrambi i casi alla fine il sw funziona.
Ma se uno sta iniziando, ritengo fondamentale instradarlo verso la 
modalità che non gli ponga vincoli o problemi in futuro.


 una e una sola applicazione...
Ci mancherebbe altro che un ufficio acquisti debba conoscere queste 
differenze...
La mia era semplicemente era una soluzione diversa da quella usata da Albe 
col timer...
Umbe 

 modalità che non gli ponga vincoli o problemi in futuro.
Rimango della mia opinione...non vedo grosse differenze se sei tu che 
sviluppi l'applicativo e la relativa gestione del barcode.
Non tutti hanno avuto le tue particolari necessità.
Nella maggior parte dei casi  è uno strumento che serve semplicemente a 
comunicare un valore, un numero, un codice al pc.
Umbe

 comunicare un valore, un numero, un codice al pc.
Mettiamola così:
Per le funzionalità che sei solito sviluppare tu, può andare bene anche 
un lettore a emulazione di tastiera. Ma non appena ti venisse chiesto 
qualcosa di 'fuori standard', potresti trovarti invischiato in problemi 
fastidiosi.
E, dico io, perchè partire con un qualcosa di meno flessibile, quando a 
parità di costo esistono oggetti che ti offrono le stesse funzionalità 
ma con metodi di comunicazione che consentono praticamente qualunque 
incastro logica/utente?
Ti faccio un esempio.
Supponiamo che oggi tu abbia il tuo software, che riceve la lettura del 
barcode in emulazione.
Domani ti chiedono che sia possibile mettere in background il tuo sw, 
perchè l'operatore può avere bisogno di usare Excel, ma che appena 
legge un codice col lettore, il tuo software torni in primo piano.
Cosa molto comune, perchè ad esempio se si alza per leggere un codice 
di un imballo enorme, potrebbe non avere il video davanti e potrebbe 
avere dimenticato aperto excel.
E se il codice va dentro ad una cella di excel gli sputtana i dati.
Come lo risolveresti?
Il modo, lo so, si troverebbe (e, per inciso, è una cosa che faccio in 
altre app).
Ma consentimi almeno che la soluzione al problema di cui sopra, non sia 
proprio così intuitiva.
Mentre, con un lettore in seriale, sarebbe una (1) riga di codice.


 Mentre, con un lettore in seriale, sarebbe una (1) riga di codice.
Ma è chiaro....come ti ho detto prima non sostengo che l'emulatore sia 
meglio del seriale.
Se tu hai sviluppato l'applicazione, avrai fatto un po' di auditing prima.
In base alle necessità/costi/tempi scegli la soluzione ideale.
Non scarto a priori una soluzione, anche perchè la seriale ha i suoi 
problemi.(distanza per esempio o i disturbi...mai provato ad usare un 
lettore vicino ad un quadro elettrico industriale con 20 inverter e carichi 
induttivi da paura?? manco si accende a momenti..sai che dati ti arrivano 
sul buffer? bisogna o passare a 485 o....ad emulatori ;-) )
Umbe 

 o....ad emulatori
Ignoravo che un cavo PS/2 fosse immune ai grossi disturbi 
elettromagnetici più di una 232.
Ne sei sicuro?


 Ne sei sicuro?
Assolutamente no. Non ho detto che Ps/2 è immune.
Ho visto pero' che delle volte funzionava meglio la ps/2 che la 232...forse 
per un discorso di massa (la 232 è single ended, non bilanciata cioè, quindi 
misurata rispetto a massa...la ps/2 non credo...ci guardo).
Umbe