Newsgroup: it.comp.appl.access
Titolo: Per @Alex : uccidere una applicazione

 ovviamente sai già la differenza tra SendMessage e PostMessage...
Certo che la so, la prima e' sincrona la seconda e' asincrona.
E credo di aver capito cosa intendi.
Vedi ... Il fatto e' che (colpa mia) non ho spiegato BENE nei
particolari quello che sto facendo.
Il problema deriva dal fatto che il DB2 IBM, nella installazione
che abbiamo da noi, pare non supporti il timeout dell' oggetto
command. Non c'e' verso. Sentiti anche i sistemisti : non
funziona.
Ora, sto sviluppando (tra le altre cose) un sistema siffatto :
gli utenti mandano via email le query piu' disparate ad una
macchina (pc) centrale, la quale usando il driver OLE DB
dell' IBM si connette al DB2, la esegue, produce un report e
lo spedisce al mittente.
Ma come tu mi insegni gli utenti sono pazzi, e potrebbero
spedire queries che richiedono MILIARDI di record o
sono ESTREMAMENTE complesse (per quanto concerne
gli errori sintattici, quelli li intercetto e gli rispondo, no
problem) o ambedue le cose.
Una query siffatta bloccherebbe il sistema anche per
un' ora, o piu' , il che gli impedirebbe di soddisfare le altre
richieste.
La soluzione piu' semplice che avevo ideato e' offerta dalla
copia timeout/recordset asincrono.
Col timeout gestisco l' attesa dal main frame, e con l' evento
fetchprogress del recorset (superato il timeout) conto i record
in arrivo. Se superano una certa soglia, butto fuori l' utente previa
notifica.
Purtroppo, il time out non funziona. Ed a quel punto e' inutile anche
l' asincronicita' del recordset, perche' i dati potrebbero cominciare
ad arrivare chissa' quando. Mi spiego ?
Sintetizzando all' inverosimile :
Allora debbo fare cosi (l' ho gia' quasi fatto, e pare funzioni) :
Produco DUE applicazioni indipendenti, un governor (G) ed un
processor (P). Il governor e' sempre in RAM, pronto ad ascoltare
le richieste (la macchina e' dedicata).
Quando arriva una richiesta G "accende" P e gliela passa, poi
si mette in attesa. Ogni tot tempo controlla P, e se viene superato
il tempo limite, lo uccide.
Ma attenzione ! P puo' essere acceso da G, ma la procedura
(in P) che si connette al DB2 e scarica i dati NON PUO' essere
chiamata da G, perche' in quel caso il blocco di P coinvolge
anche il G. Per ovvi motivi.
Occorre invece che P sia anch' esso dotato di un timer (che
si attiva all' apertura), che con una chiamata in call back scatena
(dopo diciamo 5 secondi dall' attivazione di P) autonomamente e
senza l' intervento di G la procedura che carica i dati.
Ora tu dici :
se la G, dopo aver attivato P, manda un postmessage con un
delay uguale al tempo limite, si otterrebbe lo stesso risultato
senza  bisogno che la G controlli ogni tot se il tempo limite
e' stato superato. Ho capito bene ?
Ma in quel caso, la G come sa' che la P e' stata uccisa, e quindi
come fa a sapere che deve avvertire l' utente ?
Non saprei ... Non c' ho ancora pensato.
Ed inoltre francamente non ho dimestichezza con la postmessage
(la conosco, ma avere dimestichezza e' ALTRA cosa).
Che ne pensi, cosa mi consigli ?

> Che ne pensi, cosa mi consigli ?
1 mese di ferie.
;)
PS
haime' non ho seguito il 3d precedente...


Ho risposto nell'altro.... mi ero perso il pezzo.
@Alex

 haime' non ho seguito il 3d precedente...
Non ti serve.