Newsgroup: it.comp.lang.visual-basic
Titolo: controllo timer. può "perdere un colpo?"

Ciao.
Poniamo che io abbia un controllo timer che si attiva ogni secondo.
al "minuto spaccato" io devo fare una cosa, anche solo un semplice
"beep".
è possibile che, per qualche ragione (computer decisamente
indaffarato) il controllo timer si "perda" il secondo?
intendo: per una volta l'evento timer NON scatta???
è possibile?
grazie.

cippalippa ha spiegato il 08/08/2005 :

Il timer genera un evento.
Il sistema operativo gestisce questo evento alla prima occasione utile.
Non è detto che questo avvenga immediatamente, esattamente come un 
click può essere gestito dopo un certo tempo.
Può essere che il sistema fosse impegnato in altre cose, o può anche 
essere che fosse il tuo sw a tenerlo impegnato (ricorda che un 
applicativo non gestisce gli eventi finchè non trova un End 
Sub/Function, se non è Idle, o se tu non forzi un DoEvents).
Ciao
Alberto
-- 
Autore di
"Petting for Dummies"

 intendo: per una volta l'evento timer NON scatta???
Secondo me sì.
-- 
Salutoni
Sergio
Per rispondere... togli il group dall'indirizzo
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

acc!, due risposte discordanti
una da un mago dell'informatica, una da un mago Baol...
OK ai doevents ecc, l'importante è che "prima o poi" lo faccia, anche
se 5 secondi dopo o un minuto dopo, ma se l'evento si è verificato,
prima o poi deve processarlo!
traduco: il mio timer parte ogni secondo. al secondo zero deve fare
delle robe.
OK se le fa 10 secondi dopo, ma DEVE farle.
che dite?
grazie bis

 OK se le fa 10 secondi dopo, ma DEVE farle.
Credo che niente meglio di un serio test o una ricerca nella KB possa 
darti al risposta.
Io devo dire di usare i timer in maniera estremamente intensa.
Devo dire di non avere mai avuto problematiche di quel tipo.
Cioè, per essere più precisi: io disegno i sw in modo tale che un 
eventuale ritardo non crei problemi. Quasi di conseguenza, succede che 
un eventuale evento 'saltato' non generi problemi, se non un warning 
nel log.
Ma non guardo i log dei software dopo il primo mesetto di tuning.
Per cui, può anche essere che la cosa avvenga, magari dopo due anni di 
esecuzione, ma io non l'ho mai osservato.
Diciamo che se ho bisogno veramente di un real-time (tipicamente per 
operazioni di automazione), con 100Euri compro un Plc e lo attacco al 
Pc. Poi la parte di real-time la fa quello.


aaaaaaaaaaaazzzzzzzzzzzzzzz non funziona.
ho messo un timer ogni secondo... ho lanciato un calcolo che dura 10
secondi (senza doevents in mezzo)...
beh, il timer si è fatto una dormitina e NON ha recuperato gli eventi.
se metto il doevents, beh, funziona ma va circa 100 volte più lento
:-(
ora almeno lo so.
grazie.

cippalippa ci ha detto :

No, ti sfugge ancora qualcosa.
Il punto è che tu probabilmente hai lanciato 'il calcolo' da dentro 
l'evento timer1_timer.
Prova a lanciarlo da un'altra sub, ad esempio dal click di un button 
mentre l'evento timer sta per scattare. Vedrai che il sistema recupera 
l'evento non appena incontra l'end sub.


 aaaaaaaaaaaazzzzzzzzzzzzzzz non funziona.
Ricorda: non è un bug, è una feature.
Nel tempo in cui il tuo programma era intento a fare qualcosa si sono
verificati più eventi click del timer. Il sistema operativo, nel momento
in cui la tua applicazionè è tornata a "rispondere", ha impacchettato
tutti questi eventi e te ne ha inviato solo uno.
Di solito, quando devo risolvere un problema simile al tuo, nell'evento
click guardo che ora è, poi controllo quand'è stata l'ultima volta che ho
fatto una determinata cosa, se è passato un certo tempo la rieseguo.
hth


 tutti questi eventi e te ne ha inviato solo uno.
Emh...
Secondo me è più probabile la mia interpretazione, cioè che il calcolo 
fosse interno all'evento stesso del timer.
Ricorda che l'evento timer scatta dopo <interval> ms dalla *fine* 
dell'esecuzione dell'evento precedente...


 fosse interno all'evento stesso del timer.
Non direi. Ho appena fatto il test da te consigliato:
un timer con interval = 1000, nella cui routine di evento c'è scritto:
debug.print time
perdonerai il cast implicitio, ma era una cosuccia fatta di fretta, e non
ho badato gran che hai dettagli.
Poi ci ho messo un bottoncino, nella cui routine di click ho scritto
dim t as date
t = now
do until abs(datediff("s", now,t)) > 10
loop
Notare il raffinato utilizzo della funzione abs, dovuta al fatto che non
ricordavo in che ordine viene effettuata la differenza :-)
Il risultato è che alla partenza del programma, ad ogni secondo viene
stampata l'ora corrente nella finestra immediata. Se schiscio il
bottoncino questa stampa viene interrotta per una decina di secondi e poi
riprende a stampare ad ogni secondo. Dei dieci eventi persi dal timer, al
limite ne ha recuperato uno solo.


 limite ne ha recuperato uno solo.
In effetti non stai dicendo niente di sbagliato. Ma è una visione 
empirica di una cosa che ha una spiegazione 'scientifica'.
Il timer aspetta <interval> ms dalla *fine* dell'ultima gestione 
evento.
Se durante i 10sec del tuo loop, viene generato un evento timer, questo 
non può essere gestito subito (il sistema non gestisce eventi finchè 
non trova End Sub), e quindi i successivi non vengono proprio 
scatenati. Al completamento del loop, parte la gestione eventi, e 
l'*unico* evento finora scatenato viene correttamente gestito.
Questa cosa dovrebbe farvi capire anche il perchè cippalippa non veda 
gli eventi avvenuti durante il *suo* calcolo. Perchè (presumo), il suo 
calcolo era *dentro* alla routine dell'evento, e quindi l'evento 
seguente non era assolutamente scatenato (non era ancora ripartito il 
contatore del timer).
Il doevents inserito in mezzo alla routine di gestione eventi, 
rilasciando il controllo al sistema per un attimo, fa ripartire anche 
il contatore del timer.


 empirica di una cosa che ha una spiegazione 'scientifica'.
Effettivamente direi che la tua spiegazione, alla luce di alcuni risultati
sperimentali, è più aderente alla realtà dei fatti.


no, è così come dice Baol.
effettivamente, il "timer" si fa un bel pisolo e riparte a contare
"quando può".
insomma, PIPOL, spargete il codice di DOEVENTS ovunque!

 insomma, PIPOL, spargete il codice di DOEVENTS ovunque!
Calma e gesso.
Rifai le tue prove, e riprendi fiducia nello strumento.
Leggi anche l'altro ramo del thread.


ecco il codice, và ;-)
(timer1.interval=1000)
------------------------------------
Private Sub Command1_Click()
Dim i As Long
Dim a As Integer
Debug.Print Format(Now, "NN:SS") & " inizio calcolo"
DoEvents
For i = 1 To 50000000
  ' per fargli fare qualcosa
  a = a + 1
  a = 0
Next
Debug.Print Format(Now, "NN:SS") & " fine calcolo"
End Sub
Private Sub Timer1_Timer()
Debug.Print Format(Now, "NN:SS")
End Sub
ed ecco il risultato:
12:53
12:54
12:55
12:56
12:57
12:58
12:58 inizio calcolo
13:05 fine calcolo
13:05
13:06
13:07

...quindi, il timer "conta" quando può.
... e appena ha tempo l'evento timer si scatena (ma UNO SOLO!)
... basta saperlo :-D

 ... basta saperlo :-D
Sappilo.


OK, ora so TUTTO.
e forse ho ADDIRITTURA capito.
non accadranno più cose inconcepibili, mai più. (escluso tutto
l'universo tranne il timer).
(sto scherzando, eh, vi ringrazio veramente!)
Grazie.
'notte.

 'notte.
In definitiva tutto si riduce a:
Se devi schedulare un backup va MOLTO bene il timer!
Se devi programmare tramite scheda I/O l'annaffiatura del giardino va
OTTIMAMENTE bene il timer!
Se devi gestire un plastico ferroviario o roba simile va SPLENDIDAMENTE bene
il timer!
Se devi gestire macchinario sciiiientifico....va MALE il timer...
Se devi fare uno studio di segnali ed acquisizione dati il timer va BUTTATO
VIA...a meno che non ti accontenti....
per fare DSP ci sono schede apposite....il SO di windows va male per fare
conteggi precisi e brevi!
certo un secondo č poco...e tanto....
forse su un pc con pochi servizi....molta ram...e con routine ottimizzate
all'osso....ce la fai a fargli fare qualcosa ogni secondo....senza perdere
un colpo!
....IMHO perň!
Dopo una settimana hai accumulato errori di tempistica
ossia (sempre imho)
di scattano a
1,0001 sec
1,003 sec
1,2 sec
e roba analoga...ossia non mi fiderei del fatto che sia passato davvero 1
sec !!!!
ma forse non ti importa!
Non so (non son guru del win32) quello che frega...
forse l'accesso all'HD...
o qualche app fatta non so come
ad esempio mi son reso conto che sul mio vecchio win2000 lanciando emule
finchč non č caricato in memoria, tutto il pc rallenta di brutto ai limiti
del "freezamento"
...tanto per dire!