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

come recuperare il vecchio e cmdo DoEvent in 
vb.net
 ?

come recuperare il vecchio e cmdo DoEvent in 
vb.net
 ?
Spero proprio di no ;-)
Con .net puoi creare thread aggiuntivi :-)
-- 
ciao, hal

 ha scritto nel messaggio
news:a60aas$ag783$1...@ID-56381.news.dfncis.de...

Cos'è un thread aggiuntivo?

 Cos'è un thread aggiuntivo?
detta "terra terra", in maniera molto semplificativa, un thread è una
parte di programma che viene eseguita "in parallelo" alle altre.
per esempio, in Outlook Express puoi cambiare messaggio o fare una
ricerca mentre stai scaricando la posta: quel processo ha -
evidentemente - più di un thread in esecuzione
cmq se ti interessano informazioni tecniche più dettagliate in merito ci
sarà sicuramente qualcuno che saprà dirti di più (Hyperioooooooonnnn ?
:))
--
Faber

 Spero proprio di no ;-)
Lo hanno eliminato?
Finalmente molta gente dovrà rassegnarsi a imparare a programmare :)
Anche se devo ammettere che in un paio di casi era comodo.
Ciao

 evidentemente - piů di un thread in esecuzione
Quindi da quello che ho capito in Vb 6 non č possibile fare ciň a meno che
non si passi l'operazione al sistema operativo (doevents).
Un'altra domanda.
Eseguire piu thread č asincrono?
perchč in questo caso con vb6 si puň simulare il "multithreading?!" con dei
timer...
Ciauz!

 ha scritto nel messaggio
news:KnQg8.36963$Ns4.1...@news2.tin.it...

Si potrà sempre usare Sleep(0)
Ciao
--
Timothy Redaelli
timothy(dot)redaelli(at)email(dot)it
-----------------------------------
Links:
Sito Comune: 
www.it-lang-vb.net
MSDN: 
msdn.microsoft.com

 timer...
Per niente!
Prova a mettere 2 timer, T1 con un loop che dura 5 secondi (o uno
sleep(5000)) e T2 e un Debug.Print in ognuno, poi fai andare.
T2 non lavora se sta lavorando T1 e viceversa.
Con i thread i due lavorano parallelamente (questo significa essere
asincroni).
Ciao


DoEvents non fa solo una Sleep(0), la Sleep(0) non richiama l'elaborazione
dei messaggi.
Ciaotutti,
*

 Cos'è un thread aggiuntivo?
I thread sono una delle parti fondamentali che costituiscono un
processo.
Ogni processo è composto da uno o più thread, ognuno dei quali esegue
il proprio codice, indipendentemente uno dall'altro.
Quindi un thread è un "flusso di esecuzione di codice".
Possono esserci più thread in esecuzione contemporaneamente.
In realtà, questo è quello che appare a nostri occhi; è il SO che
gestisce lo scheduling dei thread (come quello dei processi), perché
il processore è in grado di eseguire un unico processo ed un unico
thread alla volta (almeno sui PC, su altre architetture non so).
Solo su macchine multiprocessore due o più processi/thread possono
essere eseguiti veramente in contemporanea (uno per processore).
I programmi VB (fino alla versione 6) sono single-thread (in realtà i
thread sono più di uno, ma solo uno è gestibile dal programmatore,
agli altri ci pensa il runtime VB).
VB.NET
 offre al possibilità di creare applicazioni multi-thread.
Ciao.
--
BSD is for UNIX-lovers -- linux is for Windows-haters.

 agli altri ci pensa il runtime VB).
[CUT]


 hai altre spiegazioni???
Sinceramente per dare una spiegazione valida al problema bisognerebbe
che postassi una parte di codice (se possibile).
Però, non mi pare che contraddica ciò che ho detto, perché il tuo
codice viene comunque eseguito in un unico thread; sugli altri (che
non hai la possibilità di creare per tua scelta) non hai nessun
controllo.
Ciao.
--


 ha scritto nel messaggio
news:KnQg8.36963$Ns4.1...@news2.tin.it...

In quel paio di casi, allora, puoi sempre usare Application.DoEvents ;-)
Ciao
--
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown


Ma... allora non cambia assolutamente niente! :PPP
Ciao

 controllo.
Metti un "textbox" in cui l'utente digita una stringa:
nel relativo evento "change" c'è questa routine
 SrcID = FreeFile
 Open "Nomefile.src" For Input As SrcID
  DestID = FreeFile
  Open "Nomefile.dst" For Output As DestID
   Do
    Line Input #SrcID, Row
    [CUT - elaborazione e modifica di Row]
    Print #DestID, Row
   Loop Until EOF(SrcID)
  Close DestID
 Close SrcID
Quando l'utente digita un carattere la routine viene eseguita e va tutto
bene su tutti i PC
Quando l'utente digita due caratteri di seguito la routine viene eseguita
due volte di seguito
ma su un PC veloce va tutto bene
su un PC lento la seconda chiamata alla routine mi da errore 55 (file già
aperto)
segno che la prima chiamata alla routine non è ancora conclusa
ipotesi: forse la routine viene chiamata due volte su due thread diversi!
verifica: creo una variabile globale "FileID"
e modifico la routine come segue
 On Error GoTo MyAlert
 SrcID = FreeFile
 Open "Licenze.prt" For Input As SrcID
  DestID = FreeFile
  Open "Licenze.htm" For Output As DestID
   FileID = DestID
   Do
    Line Input #SrcID, Row
    [CUT - elaborazione e modifica di Row]
    Print #DestID, Row
   Loop Until EOF(SrcID)
  Close DestID
 Close SrcID
Exit Sub
MyAlert:
 Select Case Err
 Case 52
  Exit Sub
 Case 55
  Close FileID
  Resume
 End Select
alla seconda chiamata della routine si ripresenta l'errore 55
questa volta però, attraverso la variabile globale "FileID", posso chiudere
il file aperto nella chiamata precedente
e attraverso un "resume" riprendere il lavoro della seconda chiamata (che è
più recente)
naturalmente, quando la prima chiamata tenterà una scrittura, trovando il
file chiuso, genererà un errore 52 (numero file non valido), ma la gestione
degli errori terminerà anticipatamente la routine (che non serve più in
quanto obsoleta)
Il corretto funzionamento di questa verifica mi porta a pensare ad un
funzionamento multithread a meno che qualcuno non abbia altre spiegazioni
...
--
Mauro
www.cerretosoft.it

 abbia altre spiegazioni
Forte del principio "val più la pratica della grammatica" ho copiato
il codice incriminato nell'evento change di un textbox, ed ho
compilato. Ho eseguito il programma ed ho controllato con Spy++. Il
processo è composto da un unico thread. Questo quindi escluderebbe un
problema legato a più thread, però in effetti mi riesce difficile
capire cosa possa causarlo.


 capire cosa possa causarlo.
E' in effetti quello che volevo dire!
Comunque, anche se nella logica del multithread, il problema è stato
risolto.
Forse ci sarà lo zampino di Guglielmo Cancelli ...
--
Mauro
www.cerretosoft.it


Ciaotutti,
*


Si perché?
--
Mauro
www.cerretosoft.it

 Si perché?
quel DoEvents consente all'utente di rientrare nella routine, anche se
la precedente non è ancora terminata. prova a toglierlo e vedrai...
--
Faber


In effetti a questo non avevo pensato;
ho l'abitudine di inserire un doevents all'interno di ogni do...loop
in quanto, se per un errore logico, la routine non dovesse uscire dal loop
almeno non mi si blocca tutto ... ma non avevo mai pensato a questo effetto
secondario
che evidentemente è tutt'altro che secondario
Grazie
--
Mauro
www.cerretosoft.it