locked
Access 2010 VBA Debugger RRS feed

  • Question

  • When I open up a custom form I created, the debugger automatically stops me at a line of code as if I set a breakpoint.  I can continue by pressing F5. This only happens the 1st time I go into the form.   If I close the database and then reopen it, then the debugger appears again.

    It only occurs on 1 specific form.  How can I stop the debugger from appearing when no breakpoints are set ????



    Thursday, May 30, 2013 7:37 PM

Answers

  • This was posted by "'69 Camaro", aka Gunny, on 13 January 2005:

    --------- begin quoted post ---------
    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.

    Press <ALT><Q> to return to Access.  Select the Tools menu -> Database
    Utilities -> Compact and Repair Database to compact the database.  When
    finished, close the database.  Open the database again and open the form in
    Form View, then enter text into the field that has recently been causing the
    problem.  The problem should be gone because you've removed the ghost
    breakpoint.
    --------- end quoted post ---------

    I usually can get results just by modifying a bit of code, then modifying it back again (just to dirty the project), then clicking Debug -> Clear All Breakpoints, then clicking Debug -> Compile. However, sometimes extreme measures are required, all the way up to decompiling.


    Dirk Goldgar, MS Access MVP
    Access tips: www.datagnostics.com/tips.html

    • Marked as answer by Dummy yoyo Thursday, June 6, 2013 6:56 AM
    Friday, May 31, 2013 1:36 AM

All replies

  • When the form opens in the debugger, click Debug | Clear All Breakpoints.

    Then click Debug | Compile database.

    might work


    peter n roth - http://PNR1.com, Maybe some useful stuff

    Thursday, May 30, 2013 8:10 PM
  • Does your database compile?
    Thursday, May 30, 2013 8:44 PM
  • A decompile usually fixes that.

    Thursday, May 30, 2013 9:58 PM
  • This was posted by "'69 Camaro", aka Gunny, on 13 January 2005:

    --------- begin quoted post ---------
    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.

    Press <ALT><Q> to return to Access.  Select the Tools menu -> Database
    Utilities -> Compact and Repair Database to compact the database.  When
    finished, close the database.  Open the database again and open the form in
    Form View, then enter text into the field that has recently been causing the
    problem.  The problem should be gone because you've removed the ghost
    breakpoint.
    --------- end quoted post ---------

    I usually can get results just by modifying a bit of code, then modifying it back again (just to dirty the project), then clicking Debug -> Clear All Breakpoints, then clicking Debug -> Compile. However, sometimes extreme measures are required, all the way up to decompiling.


    Dirk Goldgar, MS Access MVP
    Access tips: www.datagnostics.com/tips.html

    • Marked as answer by Dummy yoyo Thursday, June 6, 2013 6:56 AM
    Friday, May 31, 2013 1:36 AM
  • Hi Dirk

    That's an interesting technique ;-)

    As this is a bytecode corruption that in my experience seldom comes alone I prefer a simple decompile of the database.

    Why it is a bytecode corruption?

    Breakpoints are stored in the byte code and in the canonical code. You see only the breakpoints in the canonical code (red dots). The runtime of VBA only sees the bytecode (compiled code of the canonical code). If it stops somewhere where you don't see a red dot this means the byte code and the canonical code are not in sync anymore. This is a corruption and a urgent warning to stop working, make a backup, decompile and then go back to work. Not doing so may result in even worse corruptions.

    Of course, your way to modify some code in this area and modify it back to the same code again results in a similar action. The part of canonical code you just changed is invalidated in the byte code and newly compiled. This way you may lose the corruption you just have seen. But only in the area where you have changed code. Other corruptions may still be in and bytecode fragments that had lost connection to the cannonical code will not be deleted this way and stay in the byte code for ever.

    Therefore the decompile is the most secure way to get rid of this obvious corruption.

    Henry

    Friday, May 31, 2013 6:51 AM
  • Therefore the decompile is the most secure way to get rid of this obvious corruption.

    No question.  But when I'm working, I don't find it worthwhile to stop and decompile every time this happens.  I know I'm going to decompile eventually anyway.

    Dirk Goldgar, MS Access MVP
    Access tips: www.datagnostics.com/tips.html

    Friday, May 31, 2013 1:11 PM