Newsgroup: it.comp.lang.visual-basic
Titolo: MScomm32

Salve a tutti,  premetto subito ch è la prima volta che posto in questo ng,
e che non utilizzo direttamente visual basic, ma la versione contenuta in
MSaccess.
Avrei la necessità di creare una routine che invii tramite modem un file
mediante dei comandi AT.
Ho postato sul ng di access, ma non ho ricevuto risposta, ho cercato su
google e ho trovato qualche messaggio in cui si parla del controllo:MScomm32
presente in visual basic che serve per inviare comandi AT al modem.
Esiste per access un controllo corrispondente per access?
Esistono esempi per poter inviare comandi ati al modem?
Grazie a chi mi risponderà!


ha scritto:

La soluzione più semplice è usare Mscomm.
Per quanto ne so MSCOMM32 è  nella dotazione di VB, non di VBA, per
cui potresti non averlo.
In alternativa si possono usare le Api di windows.
E' una strada più difficile, ma se non hai alternative...
Scaricati la guida delle API:
http://members.xoom.virgilio.it/CesareRizzi/Raccolta%20API.chm
Funzioni CreateFile, WriteFile, ReadFile  ecc..
In particolare trovi l'esempio:
http://members.xoom.virgilio.it/CesareRizzi/Esempi/RS232.zip
che usa le API per aprire una connessione seriale.
Se non ricevi qualche consiglio migliore, puoi provare questa strada.
ciao
  Stefano

 ha scritto nel messaggio
news:qaEZd.13891$Tm5.2...@twister2.libero.it...

Ciao Ciroteo...! ;-)
Se non ricordo male accennavi all'uso di ODE 2003, che se non erro
è contenuto in VisualStudio....!
In questo caso il controllo al quale ti riferisci è incluso nella
possibilità
di distribuzione, lo stesso controllo funziona in VBA da quanto ne sò...!
Ciao.
-- 
@Alex (Alessandro Baraldi)
---------------------------------------------------------------------------
http://www.sitocomune.com/
http://www.mantuanet.it/alessandro.baraldi/
---------------------------------------------------------------------------

 ha scritto nel messaggio
news:j2be31dqjqpoctkaj...@4ax.com...


 Tullio
Andrea

comunicazione seriale si interrompe per brevi momenti (cosa che mi genera problemi)
Beh, certo che se hai dei vincoli di tempo stretti per la
comunicazione come ad esempio nella gestione di una RS485 dove devi
'girare' la porta appena finita la trasmissione stringa, e l'utente ha
10 finestre aperte hai dei problemi, ma la colpa è di windows e della
sua gestione dei tasks, e comunque ci sono dei rimedi.(esterni)
 ciao
   Stefano

 ha scritto nel messaggio
news:j2be31dqjqpoctkaj...@4ax.com...

Ok grazie mille provo a vedere se riesco a trovare qualcosa .

 ha scritto nel messaggio
news:423773fb$0$6306$5fc...@news.tiscali.it...

Grazie alex, per il momento ho suggerito al cliente di acquistare la ode
2003 però devo darmi da fare con il mio access fintanto che si decidano ad
acquistarla ...

 ha scritto nel messaggio
news:i4tf311joavq6j7m5...@4ax.com...


del genere.
Non ne ho idea, certo che se 'vuole' il pc può essere molto veloce, ma
la documentazione sul s.o. a questo livello non si trova.
Io comunque ho risolto in un altro modo.
ciao
  Stefano

 ha scritto nel messaggio
news:s2fg31l04vmcd274l...@4ax.com...


risolvere e mettere a disposizione di tutti qualcosa di utile e definitivo.
Per ora ho ti risposto solo io,  ma speriamo che si accodi qualcuno
che ne sa di più...
ciao
   Stefano

 ha scritto nel messaggio
news:v9ii31h6uikenmo65...@4ax.com...


sperimentare provando ad eliminarlo per usare solo gli sleep.
Se fai vedere qualche esempio di codice ti posso dare un parere.
Ciao
    Stefano

 sbagliando?
A monte.
La comunicazione TCP/IP non garantisce a sufficienza i tempi.
Per questo motivo, le applicazioni che 'tutto il mondo' sviluppa, devono 
essere pensate in modo tale da non avere problemi in caso di piccoli 
ritardi.
In generale, infatti, la periferica remota è sufficientemente intelligente 
da poter vivere almeno n millisecondi senza ricevere pacchetti, e se è una 
periferica di acquisizione, deve poter bufferizzare ciò che riceve.
Se serve un tempo certo, l'unica via è la seriale (485 o 422 se la distanza 
lo richiede), e a questo punto anche MSComm è perfettamente efficiente.
Attraverso Api, puoi impostare la priority del processo, ottenendo quindi 
l'affidabilità dei tempi e la pronta disponibilità di Cpu al bisogno.
Ciao
Alberto
-- 
E tutto mi sembrava andasse bene... 

 ha scritto nel messaggio
news:5v4l31teisnvhfc98...@4ax.com...


 inevitabile.
Effettivamente questo lo escludevo.
Noi sviluppiamo cose abbastanza simili alle tue, ma non esiste proprio che 
la parte interattiva sia lo stesso processo che gestisce la comunicazione.
Noi realizziamo servizi NT che si occupano della comunicazione (seriale, 
Tcp/Ip, file sharing, insomma, quello che serve), e a parte facciamo delle 
consolle utente.
Ogni servizio, all'avvio, innalza (o anche abbassa, dipende) la propria 
priorità in ambito NT, in modo da distribuire la disponibilità di Cpu 
secondo le reali necessità.
Il sistema operativo viene poi configurato per dare priorità al background, 
per cui le consolle interattive passano in bassa priorità.
In linea di massima, comunque, le consolle possono anche essere in rete, per 
cui capita di avere la macchina NT senza monitor e tastiera, gestita da Lan 
con consolle o, per cose molto invasive, da Terminal Server.


 ha scritto nel messaggio
news:39vnevF...@individual.net...


 Usate vb o altri linguaggi?
VB6 SP5


con consolle o, per cose molto invasive, da Terminal Server.
Questi 'servizi' sono eseguibili creati con C++ ?
La cosa mi interessa, soprattutto per la possibilità di gestire la
priorità.
Hai qualche link o documentazione in proposito?
Ciao
  Stefano

 priorità.
La priorità la puoi gestire per qualunque processo, non è una peculiarità 
dei servizi.
Cerca su 
allapi.net
 qualcosa del tipo SetThreadPriority o simile.


 ha scritto nel messaggio
news:39vv3hF...@individual.net...


risolve tutto
Mah, forse una rielaborazione del protocollo ti può aiutare
ciao
     Stefano

 ha scritto nel messaggio
news:gail315vas7dnq53i...@4ax.com...


memoria
Si, ma da come l'ha descritta Albe è come maneggiare un riccio di
mare...
Ho trovato qualcosa sui processi qui:
http://www.disi.unige.it/person/DelzannoG/SO1/schedx4.pdf
In particolare:
  I processi possono settare la classe priorità di processo
 (Api SetPriorityClass)
  I singoli thread possono settare la priorità di thread
 (Api SetThreadPriority)
 Queste determinano la priorita di base dei thread
 I thread (NON i processi) vengono raccolti in code ordinate per
priorità, ognuna gestita round robin. 
Quattro classi: system (\real time", ma non è vero), utente, zero,
idle.
ciao
      Stefano

 idle.
Beh, 'real time' secondo il concetto Windows, non certo quello di un plc con 
un tempo di ciclo prefissato.
Però, io ho provato, e col RealTime un thread si prende veramente tutta la 
Cpu (tanto che anche il resto del sistema diventa pressochè inutilizzabile).
Più che sull'elevare la priorità del thread su cui lavoriamo, io tendo a 
abbassare la priorità di tutti quelli che possono anche permettersi dei 
ritardi (tipo quelli che lavorano in rete). Impostando quelli come 'idle', 
restano tante risorse disponibili per i thread che metti a alto livello (a 
memoria, tra l'altro, ricordavo 5 classi, non 4...).
E' evidente comunque che il sistema deve essere un qualcosa di decente 
(quindi rigorosamente un NT), e ottimizzato per il background anzichè 
l'interattivo.
Potendoselo permettere (nel senso di non avere necessità particolari con 
applicativi 'nuovi') il sistema migliore è un NT4SP6. Leggerissimo, montato 
su una macchina odierna diventa un fulmine. Stabilissimo.
In subordine, in ordine decrescente di preferenza, uso W2000 Server, 
W2003Server, W2000Pro, XP Pro.


e ripresa del servizio.
Ho trovato questo che spiega i servizi:
http://www.visual-basic.it/articoli/agNTServ2.htm
e c'è anche la vecchia versione:
http://shorterlink.com/?7CTYGW
e qui l'oggetto in questione:
http://digilander.iol.it/VBItalia/files/ntsvc.exe
ciao
  Stefano