Newsgroup: it.comp.lang.visual-basic
Titolo: [?] processi cooperanti?

Il problema è il seguente:
scrivo due programmi VB independenti; li mando entrambi in esecuzione:
il programma A, ad un certo punto si "rende conto" che B deve compiere
una certa azione e deve riuscire a fargliela compiere.
La soluzione che ho trovato (ma che non mi soddisfa) potrebbe essere
quella di un "semaforo": B, tramite un timer, testa un buffer in cui A
va a scrivere se è il momento di eseguire l'azione; ovviamente B
elabora il test (sprecando risorse) peraltro temporizzato a livelli
abbastanza bassi.
Pur ignorando la programmazione avanzata in VB, ho subodorato che
forse, tramite handle delle applicazioni, si può fare senza timer (e
conseguente "attività" di B) ma non so come .....................
sbaglio?
se non sbaglio, come si fa?
grazie per l'attenzione
ciao
marzio


La tecnica da te utilizzata non è sbagliata, anche se, personalmente cerco
sempre di evitare di utilizzare timer.
Immagino che per notificare le "operazioni" tra le applicazioni usi un file
(comune ai 2 programmi).
Non credo che se sia possibile, recepire o inviare degli eventi tra
un'applicazione e l'altra, con delle sole API (visto che hai parlato di
handle).
Tuttavia ti posso consigliare 2 metodi.
1) utilizzare, al posto del file, delle variabili di sistema (atomi), le
quali sono praticamente di tipo boolean (perchè o esistono o non esistono);
per esempio potresti creare,dal processo A, l'atomo A1 per avvisare il
processo B (sempre tramite timer) che il processo A ha generato un evento ;
Questa tecnica ti permette di evitare l'utilizzo dei file che implicano
l'utilizzo di operazioni su disco (molto lente, pesanti e bloccanti). In
questo modo potresti impostare la proprietà interval del timer anche a 1
secondo (se vuoi anche a meno).
Questa prima soluzione ti permette di riscrivere poco codice (a quello che
hai già sviluppato) e migliorare notevolmente le prestazioni.
2) La migliore soluzione (secondo me) è quella di utilizzare una DLL ActiveX
(o addirittura un EXE Activex). In questo modo potresti gestire degli eventi
veri e propri. Se dal processo A vuoi mandare un messaggio al processo B
(vuol dire generare un evento al processo B), ti basterà semplicemente
richiamare un metodo dal processo A (del tipo istanza.sendmessage
"Messaggio").
I vantaggi sono innumerevoli; primo tra tutti è la scalabilità
(caratteristica in genere della OOP); inoltre, una volta creato il
componente, avrai a disposizione un codice semplice sia da utilizzare che da
leggere.
Fammi sapere quale sarà la tua scelta .. in tutti i due i casi, potrei
fornirti dei semplici esempi ...
            Ciao
        Davide

Piccola correzione del punto 2 ...
è possibile utilizzare solo componenti EXE ActiveX e non DLL ...
Saluti
        Davide

 ha scritto nel messaggio
news:3a2050bb...@news.tin.it...

in maniera molto semplice utilizza COM;
1) crea una ActiveX EXE che espone una determinata classe di interfaccia,
con proprietà, metodi ed eventi opportuni; tale classe farà riferimento ad
un modulo interno dove saranno memorizzati i dati da scambiare
2) crea i 2 programmi, in modo da referenziare tale ActiveX, ed usa la
classe esposta per comunicare tutto ciò che vuoi
fai riferimento alla documentazione su MSDN;
adesso vado di fretta, ma se ne hai bisogno potrei anche impostarti
qualcosa;
fammi sapere
ciao


Io ho lo stesso problema (l'ho chiesto al NG poco tempo fa) creando un EXE
activeX non riesco a far procedere il processo B (l'EXE activeX)  in maniera
asincrona in modo che il processo A possa continuare l'esecuzoine di
comandi.
Potresti postare un  qualche esempio dove si possa capire come risolvere il
problema?
Ciao
biXso

 problema?
Una soluzione *molto* artigianale per avere metodi asincroni e' quella di
ritardare con un timer l'esecuzione del metodo "vero", piu' o meno cosi':
Public Sub AsyncMioMetodo()
    Timer1.Tag="MioMetodo"
    Timer1.Enabled=True
    'il timer puo' avere l'intervallo che vuoi, diciamo 50ms.
    'A questo punto il controllo ritorna al chiamante.
End Sub
Private Sub Timer1.Timer
    'disabilitiamo subito il Timer e processiamo la chiamata
    Timer1.Enabled=False
    CallByName Me, Timer1.Tag, vbMethod
End Sub
Private Sub MioMetodo()
    'il codice "vero", come sistema di notifica del completamento puoi
utilizzare
    'un "RaiseEvent" o una variabile pubblica booleana tipo "IsProcessing"
    'Volendo puoi anche lasciare "Public" questo metodo in modo da avere la
    'scelta tra chiamata sincrona/asincrona.
End Sub
Lo so, non e' bello ma dovrebbe andare...per evitare di usare controlli visuali
nel tuo programma puoi implementare il timer con le API SetTimer/KillTimer e
funzione di callback.
Ciao
--
Luca Dormio
luca....@tin.it
luca....@sig-la.com


la mia soluzione è:
il programma B scrive in un file (o nel registro) l'hWnd di una TextBox,
nascosta, che ha in una qualunque Form...
quando il programma A deve far eseguire qualcosa al programma B, legge
l'hWnd dal file e usa PostMessage con WM_SETTEXT per impostare il testo
della TextBox ... a questo punto nel programma B viene scatenato l'evento
Text1_Change, e il resto lo lascio alla tua immaginazione  :)
più semplice a farsi che a dirsi!
Ciauz
Faber


Nel mio primo post ho scritto :
"Non credo che se sia possibile, recepire o inviare degli eventi tra
un'applicazione e l'altra, con delle sole API (visto che hai parlato di
handle)."
fortuna che ho messo "credo" ...
Grazie Faber