Newsgroup: it.comp.appl.access
Titolo: Troppi DoEvents?!

Vi risulta che l'abuso di DoEvents crei problemi di chiusura improvvisa di 
Access 2003?
Grazie
Daniele 

OneEDP ha scritto:

No.
Che intendi per abuso?
do until i>10^7
	i=i+1
	doevents
loop
tipo questo?
--
ac

"OneEDP" <OneEDP@antispam> ha scritto nel messaggio 
news:49a67b3d$0$1114$4faf...@reader2.news.tin.it...

Sě. Troppi doevents, specie in un ciclo, consumano (potrebbero) lo stack di 
memoria a disposizione dell'applicativo.
Poi dipende da dove č usato...creando anche altri tipi di problemi.
Per uno sguardo (versione 2007):
http://office.microsoft.com/it-it/access/HA012288271040.aspx
Ciao, Carlo 

"OneEDP" <OneEDP@antispam> wrote in message 
news:49a67b3d$0$1114$4faf...@reader2.news.tin.it...

Per quante volte l'abbia inserito credendolo di qualche utilità,
per tante volte l'ho poi tolto non avendone riscontrata alcuna.
Sarei lieto qualcuno me ne desse dimostrazione contraria.
Bruno 

 ha scritto nel messaggio 
news:0Avpl.45603$8Z.4...@tornado.fastwebnet.it...

1° Prima finestra on Timer
2° Seconda finestra on Timer
3° Private WithEvents cnn As ADODB.Connection
4° While cnn.state = adStateExecuting ... DOEvents (PIGRIZIA)
5° Procedura chiamante
Una sorta di nidificazione
Daniele

 ha scritto nel messaggio 
news:49a69d6b$0$841$4faf...@reader5.news.tin.it...

Copio e incollo
"Sospende l'esecuzione in modo che il sistema operativo possa elaborare 
altri eventi." in coda
Perché, in una elaborazione lunga, devi constringere l'utente a stare 
piantato e non darli la possibilità di annullare, effettuare altre 
elaborazioni, effettuare il refresh dello schermo, visualizzare lo stato di 
avanzamento lavori, ecc, ecc, ecc specialmente su pc più datati.
Tieni presente che tutto il Jet funziona così mentre si visualizzano le 
informazioni sulle maschere.
Ad all'utente gli è stata data la possibilità di richiedere milioni di 
record sul server (esaspero) e non esiste nessun DoEvents, non avrà mai la 
possibilità di ripensarci.
Inoltre DoEvents lo trovo molto utile in fase di debug, altrimenti non 
riuscirei a "vedere" quello che succede.
Ciao
Daniele 

 riuscirei a "vedere" quello che succede.
Questa invece non la so.
Se me la rispiegassi...
Bruno 

 Bruno 

 opportunamente i testi da visualizzare e quindi riesco a "vedere"
Queste parole di colore oscuro
        vid'io scritte al sommo d'una porta
        per ch'io: "Maestro il senso lor m'è duro"
Ma non ti preoccupare e grazie della disponibilità.
Bruno 

OneEDP ha scritto:

Uhmmm temo che sei incappato in cio' che Carlo ti ha evidenziato con il 
link.
Personalmente evito di attivare piu' di un timer. L'evento di timer, mi 
e' successo per una procedura vb(meglio non rivangare, se ci penso 
ancora ho voglia di sodomizzare colui che mi aveva attivato 5 timers), 
scatta anche se il sistema sta ancora elaborando altre cose.
Quando ho una situazione di attesa (adStateExecuting, o come mi sta 
capitando in una applicazione che ho appena fatta [READYSTATE_COMPLETE])
generalmente uso la funzione sleep (sleep va "declarata") per evitare i 
cicli molto stretti
i.e.
     wb01.Navigate2 sModello
     Do until wb01.ReadyState
         DoEvents
         Sleep 200
     Loop
in questo caso perdo al massimo 0,2sec ma cosa sono in confronto 
all'eternita!
--
ac

Bruno Campanini ha scritto:

  Ed elli a me, come persona accorta:
«Qui si convien lasciare ogne sospetto;
ogne viltà convien che qui sia morta.
Noi siam venuti al loco ov' i' t'ho detto
che tu vedrai le genti dolorose
c'hanno perduto il ben de l'intelletto».
Ahhh....l'nfernale terzo canto, uno dei miei preferiti
--
ac


Con adStateExecuting Sleep 200 è troppo leggera e Access di chiude 
inesorabilmente!
Aumentando il time questo non succede.
Nel mio caso
While .State = adStateExecuting
                    Debug.Print Now()
                    DoEvents
                    Sleep 200
Wend
Debug.Print "Fine", Now()
ho notato che DoEvents non viene immediatamente percepita (perché 
evidentemente ci sono altri task in coda).
In ogni caso ritengo che essendoci al massimo tre stack di chiamate e UN 
solo On Timer su una form, Access non è che sia proprio un fenomeno di 
stabilità.
Allora mi è venuto in mente  che esiste questo bellissimo leggerissimo 
freeware che permette di assegnare dinamicamente la CPU in modo automatico o 
mirato per applicazione e così l'ho provato subito.
Impostando MSACCESS.EXE Below Normal (per sicurezza) su un PC con E5200 non 
ho più la necessità di impostare alcuno sleep e posso stare tranquillo che 
non esaurirò gli stack con i vari timer e doevents
http://www.pcprofessionale.it/2008/11/26/download-del-giorno-process-tamer/
Che ne pensi se lo rendiamo noto anche agli altri del NG in modo più 
esplicito.
Grazie mille
Daniele

 ha scritto nel messaggio 
news:2TApl.46067$8Z.4...@tornado.fastwebnet.it...

Scusami se forzo il thread. Le cose sono quasi pertinenti.
Con adAsyncExecute non ottengo i record esaminati.
Puoi aiutarmi ... il thread inizia non "Banale....."
Grazie 

 esplicito.
Queste segnalazioni sono sempre utili, cionontoglie preferisco evitare 
"nodi" aggiuntivi quando possibile.
--
ac