fIsAppRunning causes code to go into Break mode

[Nicholas Scarpinato]

I'm running code at database startup to determine if Outlook is running, and
if not, open it. However, when the line of code that calls the function is
executed, the database goes into Break mode without displaying any error
message at all.

Here's the code:

Private Sub Form_Load()
On Error Resume Next
Debug.Print "Linking Tables"
Call LinkVersionTable
' Populate module level variables when form loads.
strVerClient = Nz(DLookup("[VersionID]", "[VersionTable]"), "")
Debug.Print strVerClient
strVerServer = Nz(DLookup("[VersionID]", "[tblVersionServer]"), "")
Debug.Print strVerServer
Debug.Print "Version Check Complete"
Debug.Print "Outlook Application Check"
If fIsAppRunning("outlook") = False Then
If Len(Dir("C:\Program Files\Microsoft Office\Office12\Outlook.exe")) > 0 Then
Shell "C:\Program Files\Microsoft Office\Office12\Outlook.exe", vbHide
Else
Shell "C:\Program Files\Microsoft Office\Office11\Outlook.exe", vbHide
Debug.Print "Outlook Application Started"
End If
Else
Debug.Print "Outlook Application Already Running"
End If
End Sub

As soon as the database tries to execute the line "If
fIsAppRunning("outlook") = False Then", it goes into Break mode. I thought
that maybe there was a glitch in the code, something mistyped or something,
but the code compiles without any errors. Up until yesterday, everything was
fine. The only thing I've changed in the fIsAppRunning code is adding a line
to check for Outlook's WindowClass (it was looking for Access before, I
forgot to change it to look for Outlook), and when I first changed that line
of code there were no issues.

 

[Dirk Goldgar]

I'm running code at database startup to determine if Outlook is running,
and
if not, open it. However, when the line of code that calls the function is
executed, the database goes into Break mode without displaying any error
message at all.

Here's the code:

Private Sub Form_Load()
On Error Resume Next
Debug.Print "Linking Tables"
Call LinkVersionTable
' Populate module level variables when form loads.
strVerClient = Nz(DLookup("[VersionID]", "[VersionTable]"), "")
Debug.Print strVerClient
strVerServer = Nz(DLookup("[VersionID]", "[tblVersionServer]"), "")
Debug.Print strVerServer
Debug.Print "Version Check Complete"
Debug.Print "Outlook Application Check"
If fIsAppRunning("outlook") = False Then
If Len(Dir("C:\Program Files\Microsoft Office\Office12\Outlook.exe")) > 0
Then
Shell "C:\Program Files\Microsoft Office\Office12\Outlook.exe", vbHide
Else
Shell "C:\Program Files\Microsoft Office\Office11\Outlook.exe", vbHide
Debug.Print "Outlook Application Started"
End If
Else
Debug.Print "Outlook Application Already Running"
End If
End Sub

As soon as the database tries to execute the line "If
fIsAppRunning("outlook") = False Then", it goes into Break mode. I thought
that maybe there was a glitch in the code, something mistyped or
something,
but the code compiles without any errors. Up until yesterday, everything
was
fine. The only thing I've changed in the fIsAppRunning code is adding a
line
to check for Outlook's WindowClass (it was looking for Access before, I
forgot to change it to look for Outlook), and when I first changed that
line
of code there were no issues.

It sounds like you've got a "ghost breakpoint". Maybe you edited the code
while in break mode? Sometimes that causes this phenomenon.

Try this to get rid of it. While *not* in break mode, modify the code in
some trivial way, and then change it back. This is just to force Access
that the VB project is "dirty". Then click Debug -> Clear All Breakpoints.
Then click Debug -> Compile. Then save the project, compact and repair the
database, and see if the problem has gone away.

 

[Nicholas Scarpinato]

Thanks Dirk, that did the trick. I'm glad somebody knew about that, I
probably never would have figured it out on my own and then at some point I
might have fixed it without ever knowing how and driven myself crazy, lol.

I'm running code at database startup to determine if Outlook is running,
and
if not, open it. However, when the line of code that calls the function is
executed, the database goes into Break mode without displaying any error
message at all.

Here's the code:

Private Sub Form_Load()
On Error Resume Next
Debug.Print "Linking Tables"
Call LinkVersionTable
' Populate module level variables when form loads.
strVerClient = Nz(DLookup("[VersionID]", "[VersionTable]"), "")
Debug.Print strVerClient
strVerServer = Nz(DLookup("[VersionID]", "[tblVersionServer]"), "")
Debug.Print strVerServer
Debug.Print "Version Check Complete"
Debug.Print "Outlook Application Check"
If fIsAppRunning("outlook") = False Then
If Len(Dir("C:\Program Files\Microsoft Office\Office12\Outlook.exe")) > 0
Then
Shell "C:\Program Files\Microsoft Office\Office12\Outlook.exe", vbHide
Else
Shell "C:\Program Files\Microsoft Office\Office11\Outlook.exe", vbHide
Debug.Print "Outlook Application Started"
End If
Else
Debug.Print "Outlook Application Already Running"
End If
End Sub

As soon as the database tries to execute the line "If
fIsAppRunning("outlook") = False Then", it goes into Break mode. I thought
that maybe there was a glitch in the code, something mistyped or
something,
but the code compiles without any errors. Up until yesterday, everything
was
fine. The only thing I've changed in the fIsAppRunning code is adding a
line
to check for Outlook's WindowClass (it was looking for Access before, I
forgot to change it to look for Outlook), and when I first changed that
line
of code there were no issues.

It sounds like you've got a "ghost breakpoint". Maybe you edited the code
while in break mode? Sometimes that causes this phenomenon.

Try this to get rid of it. While *not* in break mode, modify the code in
some trivial way, and then change it back. This is just to force Access
that the VB project is "dirty". Then click Debug -> Clear All Breakpoints.
Then click Debug -> Compile. Then save the project, compact and repair the
database, and see if the problem has gone away.

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)