Debugger runs but unwanted

[Don]

In a form, I have a print button with the code that follows. My problem is
when I press the print button the debugger runs as if I toggeled a break
point. The first line of code is highlighted and I can press f8 all the way
through the code without an error. I did not set a break point. Why is this
happening and what can I do to stop it?

Private Sub Command29_Click()
On Error GoTo Err_Command29_Click


If IsNull(Me.PrintDate) And IsNull(Me.Date) Then

MsgBox "You did not enter a Work Order. Enter a Work Order, including the
Date, then press the Submit And Print Order Button."
Cancel = True
Else
Me.Refresh

Dim stDocName As String
stDocName = "WorkOrderLocalRpt"
DoCmd.OpenReport stDocName, acNormal, , "[WorkOrderId] = " & [WorkOrderId]


Dim stDocName1 As String
stDocName1 = "WorkOrderNetPrint"
DoCmd.OpenReport stDocName1, acNormal, , "[WorkOrderId] = " &
[WorkOrderId]


If IsNull(Me.PrintDate) Then
Me.DidNotPrint = "No"
CurrentDb.Execute "Update WorkOrderNetwork set
WorkOrderNetwork.[PrintDate] = Now"
'dbFailOnError
End If
End If

Me.Requery

Exit_Command29_Click:
Exit Sub

Err_Command29_Click:
' MsgBox Err.Description
Resume Exit_Command29_Click

 

[Jack Leach]

Sometimes I get this when I develop in 2003... breakpoints will leave a
"ghost" behind under certain curcumstances. The leading cause seems to be
editing while in debug mode (which you should avoid anyway), and sometimes
compiling with the breakpoint set. Closing and re-opening the app sometimes
gets rid of it, sometimes not. Sometimes it goes away all on its own.

The only surefire way I know of to get rid of it is by preventing it
(careful you don't edit in degub mode and don't compile with a break set),
making an MDE, or importing into a new db or copy/pasting into a new module
and removing the old.

For the record, you can hit ctl+shift+F8 to jump through the current
procedure without having to step every line.


--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

 

[Don]

Jack,

Where else can I learn about such an obscure detail such as this? You are
right on, it is 2003 I was using and no one ever told me not to edit or
compile during the debug mode in any version. I will definately keep that
little tidbit in mind in the future.

Thank you!,

Dennis

Sometimes I get this when I develop in 2003... breakpoints will leave a
"ghost" behind under certain curcumstances. The leading cause seems to be
editing while in debug mode (which you should avoid anyway), and sometimes
compiling with the breakpoint set. Closing and re-opening the app sometimes
gets rid of it, sometimes not. Sometimes it goes away all on its own.

The only surefire way I know of to get rid of it is by preventing it
(careful you don't edit in degub mode and don't compile with a break set),
making an MDE, or importing into a new db or copy/pasting into a new module
and removing the old.

For the record, you can hit ctl+shift+F8 to jump through the current
procedure without having to step every line.


--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

In a form, I have a print button with the code that follows. My problem is
when I press the print button the debugger runs as if I toggeled a break
point. The first line of code is highlighted and I can press f8 all the way
through the code without an error. I did not set a break point. Why is this
happening and what can I do to stop it?

Private Sub Command29_Click()
On Error GoTo Err_Command29_Click


If IsNull(Me.PrintDate) And IsNull(Me.Date) Then

MsgBox "You did not enter a Work Order. Enter a Work Order, including the
Date, then press the Submit And Print Order Button."
Cancel = True
Else
Me.Refresh

Dim stDocName As String
stDocName = "WorkOrderLocalRpt"
DoCmd.OpenReport stDocName, acNormal, , "[WorkOrderId] = " & [WorkOrderId]


Dim stDocName1 As String
stDocName1 = "WorkOrderNetPrint"
DoCmd.OpenReport stDocName1, acNormal, , "[WorkOrderId] = " &
[WorkOrderId]


If IsNull(Me.PrintDate) Then
Me.DidNotPrint = "No"
CurrentDb.Execute "Update WorkOrderNetwork set
WorkOrderNetwork.[PrintDate] = Now"
'dbFailOnError
End If
End If

Me.Requery

Exit_Command29_Click:
Exit Sub

Err_Command29_Click:
' MsgBox Err.Description
Resume Exit_Command29_Click

 

[Klatuu]

All you really have to do is open the module where the debug is stopping the
code, select Clear All Breakpoints from the Debug menu, recompile and save.
--
Dave Hargis, Microsoft Access MVP

Jack,

Where else can I learn about such an obscure detail such as this? You are
right on, it is 2003 I was using and no one ever told me not to edit or
compile during the debug mode in any version. I will definately keep that
little tidbit in mind in the future.

Thank you!,

Dennis

Sometimes I get this when I develop in 2003... breakpoints will leave a
"ghost" behind under certain curcumstances. The leading cause seems to be
editing while in debug mode (which you should avoid anyway), and sometimes
compiling with the breakpoint set. Closing and re-opening the app sometimes
gets rid of it, sometimes not. Sometimes it goes away all on its own.

The only surefire way I know of to get rid of it is by preventing it
(careful you don't edit in degub mode and don't compile with a break set),
making an MDE, or importing into a new db or copy/pasting into a new module
and removing the old.

For the record, you can hit ctl+shift+F8 to jump through the current
procedure without having to step every line.


--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

In a form, I have a print button with the code that follows. My problem is
when I press the print button the debugger runs as if I toggeled a break
point. The first line of code is highlighted and I can press f8 all the way
through the code without an error. I did not set a break point. Why is this
happening and what can I do to stop it?

Private Sub Command29_Click()
On Error GoTo Err_Command29_Click


If IsNull(Me.PrintDate) And IsNull(Me.Date) Then

MsgBox "You did not enter a Work Order. Enter a Work Order, including the
Date, then press the Submit And Print Order Button."
Cancel = True
Else
Me.Refresh

Dim stDocName As String
stDocName = "WorkOrderLocalRpt"
DoCmd.OpenReport stDocName, acNormal, , "[WorkOrderId] = " & [WorkOrderId]


Dim stDocName1 As String
stDocName1 = "WorkOrderNetPrint"
DoCmd.OpenReport stDocName1, acNormal, , "[WorkOrderId] = " &
[WorkOrderId]


If IsNull(Me.PrintDate) Then
Me.DidNotPrint = "No"
CurrentDb.Execute "Update WorkOrderNetwork set
WorkOrderNetwork.[PrintDate] = Now"
'dbFailOnError
End If
End If

Me.Requery

Exit_Command29_Click:
Exit Sub

Err_Command29_Click:
' MsgBox Err.Description
Resume Exit_Command29_Click

 

[Jack Leach]

Dave's suggestion sometimes works and sometimes doesn't, IME.

While the designer allows you to edit in debug mode, it's not really a good
idea. Besides issues like these, before I stopped doing it, I'd notice that
some things I would change and after I was done and next time I opened the db
they would be gone, like I never changed them.

Some questioning in the groups here gave the explaination. I don't fully
understand the details, but basically when you're working in debugging code
like that and start making changes, you're actually working on a seperate set
of code than whats really running (the stuff running is further compiled by
access, or whatever compiles it further), and access and vba are easily
confused when it comes to to keeping these versions straight. Apparently
there's about seven various different states of compilation with a vba
project, and when you start changing code in debug mode, you're crossing a
lot of lines that are better left untouched.

So even though you are technically allowed to, it's not a good idea. I've
run into many less strange problems since I stopped doing it.

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

Jack,

Where else can I learn about such an obscure detail such as this? You are
right on, it is 2003 I was using and no one ever told me not to edit or
compile during the debug mode in any version. I will definately keep that
little tidbit in mind in the future.

Thank you!,

Dennis

Sometimes I get this when I develop in 2003... breakpoints will leave a
"ghost" behind under certain curcumstances. The leading cause seems to be
editing while in debug mode (which you should avoid anyway), and sometimes
compiling with the breakpoint set. Closing and re-opening the app sometimes
gets rid of it, sometimes not. Sometimes it goes away all on its own.

The only surefire way I know of to get rid of it is by preventing it
(careful you don't edit in degub mode and don't compile with a break set),
making an MDE, or importing into a new db or copy/pasting into a new module
and removing the old.

For the record, you can hit ctl+shift+F8 to jump through the current
procedure without having to step every line.


--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

In a form, I have a print button with the code that follows. My problem is
when I press the print button the debugger runs as if I toggeled a break
point. The first line of code is highlighted and I can press f8 all the way
through the code without an error. I did not set a break point. Why is this
happening and what can I do to stop it?

Private Sub Command29_Click()
On Error GoTo Err_Command29_Click


If IsNull(Me.PrintDate) And IsNull(Me.Date) Then

MsgBox "You did not enter a Work Order. Enter a Work Order, including the
Date, then press the Submit And Print Order Button."
Cancel = True
Else
Me.Refresh

Dim stDocName As String
stDocName = "WorkOrderLocalRpt"
DoCmd.OpenReport stDocName, acNormal, , "[WorkOrderId] = " & [WorkOrderId]


Dim stDocName1 As String
stDocName1 = "WorkOrderNetPrint"
DoCmd.OpenReport stDocName1, acNormal, , "[WorkOrderId] = " &
[WorkOrderId]


If IsNull(Me.PrintDate) Then
Me.DidNotPrint = "No"
CurrentDb.Execute "Update WorkOrderNetwork set
WorkOrderNetwork.[PrintDate] = Now"
'dbFailOnError
End If
End If

Me.Requery

Exit_Command29_Click:
Exit Sub

Err_Command29_Click:
' MsgBox Err.Description
Resume Exit_Command29_Click

 

[Klatuu]

Jack,

I did not mean to imply it is okay to edit in debug mode. I agree it is a
bad idea. I have never had the solution I posted not work. My guess would
be that if it does not, you might be looking at some corruption. In this
case, here is what I would try. Copy the entire module into a text file.
Delete the module, do a compact an repair (hopefully a decompile will not be
necessary), create a new blank module and paste the original into the new
module and compile.
--
Dave Hargis, Microsoft Access MVP

Dave's suggestion sometimes works and sometimes doesn't, IME.

While the designer allows you to edit in debug mode, it's not really a good
idea. Besides issues like these, before I stopped doing it, I'd notice that
some things I would change and after I was done and next time I opened the db
they would be gone, like I never changed them.

Some questioning in the groups here gave the explaination. I don't fully
understand the details, but basically when you're working in debugging code
like that and start making changes, you're actually working on a seperate set
of code than whats really running (the stuff running is further compiled by
access, or whatever compiles it further), and access and vba are easily
confused when it comes to to keeping these versions straight. Apparently
there's about seven various different states of compilation with a vba
project, and when you start changing code in debug mode, you're crossing a
lot of lines that are better left untouched.

So even though you are technically allowed to, it's not a good idea. I've
run into many less strange problems since I stopped doing it.

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

Jack,

Where else can I learn about such an obscure detail such as this? You are
right on, it is 2003 I was using and no one ever told me not to edit or
compile during the debug mode in any version. I will definately keep that
little tidbit in mind in the future.

Thank you!,

Dennis

Sometimes I get this when I develop in 2003... breakpoints will leave a
"ghost" behind under certain curcumstances. The leading cause seems to be
editing while in debug mode (which you should avoid anyway), and sometimes
compiling with the breakpoint set. Closing and re-opening the app sometimes
gets rid of it, sometimes not. Sometimes it goes away all on its own.

The only surefire way I know of to get rid of it is by preventing it
(careful you don't edit in degub mode and don't compile with a break set),
making an MDE, or importing into a new db or copy/pasting into a new module
and removing the old.

For the record, you can hit ctl+shift+F8 to jump through the current
procedure without having to step every line.


--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)



:

In a form, I have a print button with the code that follows. My problem is
when I press the print button the debugger runs as if I toggeled a break
point. The first line of code is highlighted and I can press f8 all the way
through the code without an error. I did not set a break point. Why is this
happening and what can I do to stop it?

Private Sub Command29_Click()
On Error GoTo Err_Command29_Click


If IsNull(Me.PrintDate) And IsNull(Me.Date) Then

MsgBox "You did not enter a Work Order. Enter a Work Order, including the
Date, then press the Submit And Print Order Button."
Cancel = True
Else
Me.Refresh

Dim stDocName As String
stDocName = "WorkOrderLocalRpt"
DoCmd.OpenReport stDocName, acNormal, , "[WorkOrderId] = " & [WorkOrderId]


Dim stDocName1 As String
stDocName1 = "WorkOrderNetPrint"
DoCmd.OpenReport stDocName1, acNormal, , "[WorkOrderId] = " &
[WorkOrderId]


If IsNull(Me.PrintDate) Then
Me.DidNotPrint = "No"
CurrentDb.Execute "Update WorkOrderNetwork set
WorkOrderNetwork.[PrintDate] = Now"
'dbFailOnError
End If
End If

Me.Requery

Exit_Command29_Click:
Exit Sub

Err_Command29_Click:
' MsgBox Err.Description
Resume Exit_Command29_Click

 

[Jack Leach]

Sorry Dave, I didn't mean that I thought you were saying it was ok to edit in
debug mode, I was just trying to give the op some further insight on my
experience with this when it used to be a problem for me.

Since I've learned not to edit in debug mode, this hasn't been an issue for
me. But there were times where clearing bp's and recompiling did not work
(it was quite frusterating). I too suspect some type of corruption when this
happens, and at the time have resorted to importing everything into a fresh
db just to be sure.

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

Jack,

I did not mean to imply it is okay to edit in debug mode. I agree it is a
bad idea. I have never had the solution I posted not work. My guess would
be that if it does not, you might be looking at some corruption. In this
case, here is what I would try. Copy the entire module into a text file.
Delete the module, do a compact an repair (hopefully a decompile will not be
necessary), create a new blank module and paste the original into the new
module and compile.
--
Dave Hargis, Microsoft Access MVP

Dave's suggestion sometimes works and sometimes doesn't, IME.

While the designer allows you to edit in debug mode, it's not really a good
idea. Besides issues like these, before I stopped doing it, I'd notice that
some things I would change and after I was done and next time I opened the db
they would be gone, like I never changed them.

Some questioning in the groups here gave the explaination. I don't fully
understand the details, but basically when you're working in debugging code
like that and start making changes, you're actually working on a seperate set
of code than whats really running (the stuff running is further compiled by
access, or whatever compiles it further), and access and vba are easily
confused when it comes to to keeping these versions straight. Apparently
there's about seven various different states of compilation with a vba
project, and when you start changing code in debug mode, you're crossing a
lot of lines that are better left untouched.

So even though you are technically allowed to, it's not a good idea. I've
run into many less strange problems since I stopped doing it.

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

Jack,

Where else can I learn about such an obscure detail such as this? You are
right on, it is 2003 I was using and no one ever told me not to edit or
compile during the debug mode in any version. I will definately keep that
little tidbit in mind in the future.

Thank you!,

Dennis


:

Sometimes I get this when I develop in 2003... breakpoints will leave a
"ghost" behind under certain curcumstances. The leading cause seems to be
editing while in debug mode (which you should avoid anyway), and sometimes
compiling with the breakpoint set. Closing and re-opening the app sometimes
gets rid of it, sometimes not. Sometimes it goes away all on its own.

The only surefire way I know of to get rid of it is by preventing it
(careful you don't edit in degub mode and don't compile with a break set),
making an MDE, or importing into a new db or copy/pasting into a new module
and removing the old.

For the record, you can hit ctl+shift+F8 to jump through the current
procedure without having to step every line.


--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)



:

In a form, I have a print button with the code that follows. My problem is
when I press the print button the debugger runs as if I toggeled a break
point. The first line of code is highlighted and I can press f8 all the way
through the code without an error. I did not set a break point. Why is this
happening and what can I do to stop it?

Private Sub Command29_Click()
On Error GoTo Err_Command29_Click


If IsNull(Me.PrintDate) And IsNull(Me.Date) Then

MsgBox "You did not enter a Work Order. Enter a Work Order, including the
Date, then press the Submit And Print Order Button."
Cancel = True
Else
Me.Refresh

Dim stDocName As String
stDocName = "WorkOrderLocalRpt"
DoCmd.OpenReport stDocName, acNormal, , "[WorkOrderId] = " & [WorkOrderId]


Dim stDocName1 As String
stDocName1 = "WorkOrderNetPrint"
DoCmd.OpenReport stDocName1, acNormal, , "[WorkOrderId] = " &
[WorkOrderId]


If IsNull(Me.PrintDate) Then
Me.DidNotPrint = "No"
CurrentDb.Execute "Update WorkOrderNetwork set
WorkOrderNetwork.[PrintDate] = Now"
'dbFailOnError
End If
End If

Me.Requery

Exit_Command29_Click:
Exit Sub

Err_Command29_Click:
' MsgBox Err.Description
Resume Exit_Command29_Click

 

[Dirk Goldgar]

Dave's suggestion sometimes works and sometimes doesn't, IME.

Here's a variation on it that was posted by "'69 Camaro", aka Gunny, on 13
January 2005:

--------- begin quoted post ---------
To fix it, open the database [...] 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 [...]. The problem
should be gone because you've removed the ghost breakpoint.
--------- end quoted post ---------

I can't vouch specifically for this procedure, because I dont think I've
tried it exactly. But on the rare occasions when I've had a phantom
breakpoint, I've been able to clear it without resorting to the "nuclear
option" of exporting the module, deleting it, and importing it again.

 

[Banana]

IME, sometime all it takes is just highlighting the troublesome line,
copying then delete the lines then insert in new blank line then paste
the line back into the new blank line and it's gone.

Regarding editing in debug mode, I personally see nothing wrong with
this. Whenever I do make edits, I usually hit 'save' and the
disappearing problem doesn't occur IME, and I tend to think this is
preferable than hitting 'Stop' when an unhandled error is raised/break