Newsgroup: it.comp.appl.access
Titolo: Ingresso in debug "non sollecitato"

Access 2003
Con una certa frequenza si verifica la situazione in oggetto.
Il sistema entra in "debug" pur non essendo presente alcun "breakpoint".
La riga su cui si ferma e'  una riga in cui precedentemente avevo 
inserito un punto di interruzione.
Non sono riuscito a capire ne perche' lo faccia ne quale sia il modo di 
dirgli che quello che sta facendo "non e' richiesto".
Se lo faccio "correre" non si interrompe piu' ma se chiudo access e 
rientro, imperterrito, si rimette in debug.
Attualmente il "workaround" che uso e' di modificare la riga e salvare, 
in questo modo "sembra" che perda il ricordo. Questo fenomeno mi sembra 
legato, ma non ne sono certo, a situazioni susseguenti a interruzione 
del debug (Esegui-->Ripristina).
La cosa comincia a diventare "annoiante" e vorrei porre rimedio.
Ogni suggerimento e' gradito
Ringraziamenti anticipati
--
ac


ciao a volte "ricorda" vecchi breakpoint
La soluzione è copiare tutto il codice, aprire la maschera,
settare "possiede modulo" a no
salvare
riaprire la form e incollare il codice stando attento a che gli eventi
vengano visti dai controlli o la form
(controllare [routine evento])
-- 
_ _
Ciao
MAssimiliano Amendola            
www.accessgroup.it
Cisa - Conferenza Italiana per Sviluppatori Access
Info:  
www.donkarl.com/it

 ha scritto nel messaggio 
news:KRchg.9808$O76....@tornado.fastwebnet.it...

ciao Alessandro,
oltre all'ottimo suggerimento di MA io ho risolto così:
fermo l'esecuzione,
inserisco tre o quattro punti interruzione 'a caso',
inserisco una riga vuota in una qualsiasi procedura,
tolgo i punti di interruzione usando la voce dal menu Debug -> Rimuovi punti 
interruzione
compilo il codice
salvo ed esco
in 10 secondi netti levi un 'segnalino' errato di MS!!!
se può servirti ....
Ivan 

 Ivan
Sě Ivan mi č capitato che non abbi afunzionato



č vero, ma 90 volte su cento basta seguire questa procedura, negli altri 
casi bisogna fare il 'trasloco' completo!
hi

 
Come si suol dire le vie del signore sono inconoscibili e le viste, come 
per il monte Fuji, molteplici
A)
VBE sometimes remembers "phantom" breakpoints.
Two ways that I use to fix this problem.
(1) Comment out the line on which the breakpoint occurs. If the code won't
compile without that line, then comment out a block of code so that the 
code
can compile without it. Compile the code. Close the database. Open the
database. Uncomment out the code. Compile the code.
(2) Use the undocumented decompile switch when opening the database so that
all compiled code is uncompiled.
"PathToAccessExecutable\msaccess.exe" /decompile
"PathToYourDataBaseFile\DatabaseFileName.mdb"
-- 
         Ken Snell
<MS ACCESS MVP>
B)
Sounds like the debugger settings were saved the last time a break point 
was
set at that line of code.  You can open and close the database repeatedly,
and the problem remains.
To fix it, open the database, then open the form in Form View.  Press
<ALT><F11> to open the VB Editor.  Click the "Reset" button on the toolbar
three times.  (Answer to question I know you are going to ask:  Because
sometimes twice just isn't enough.)  Select the Debug menu -> Compile
<DatabaseName>, just in case the code wasn't already compiled.
Gunny
--
ac


In alternativa al mio suuggerimento useri il numero (1)
