Results 1 to 8 of 8
  1. #1
    Join Date
    Jun 2008
    Posts
    5

    Unanswered: Persistent Breakpoints

    Is there a way to force a breakpoint to remain even after the app has been closed and reopened.

    Currently, I am trying to track and an error that happens when a user is logged on. Basically, I open the app, bypass the startup procedure, place the breakpoint, close the app and reopen it and the app is not hitting the breakpoint.

  2. #2
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    No.

    What you should do is write an error reporting function that writes the variables you want to monitor to somewhere (text file or a table perhaps). Then call it in the error handler of the procedure that is giving you trouble.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  3. #3
    Join Date
    Jun 2008
    Posts
    5
    Thanks. I'll try that.

  4. #4
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    You're welcome
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  5. #5
    Join Date
    Dec 2002
    Location
    Préverenges, Switzerland
    Posts
    3,740
    although i agree with Trekkers suggestion that it is very useful to log errors and startup processes, the real answer to your question is more-or-less yes:
    Stop
    acts as a permanent breakpoint - delete it when done debugging.

    izy
    currently using SS 2008R2

  6. #6
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    I can't believe I didn't think of that tbh.

    Apologies if I have over-complicated things.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  7. #7
    Join Date
    Jun 2008
    Posts
    5
    Thanks. That's what I needed. I think I will use an output file also so that when I deploy it, I'll know what the variables are when something doesn't work correctly.

  8. #8
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    I (used to) like to enclose Stop commands in conditional statements reading a boolean variable value (called something like isDebugging) so I only had to change that when deploying. If you use the #If...#Else construct then there is also no cost in the deployed app.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •