Detect if Debugger is Attached in VB6
Here is what we are using that does not have any side effects
Public Property Get InIde() As Boolean
Debug.Assert pvSetTrue(InIde)
End Property
Private Function pvSetTrue(bValue As Boolean) As Boolean
bValue = True
pvSetTrue = True
End Function
Here's a function I've been using:
Private Function RunningInIde() As Boolean
On Error GoTo ErrHandler
Debug.Print 1 / 0
ErrHandler:
RunningInIde = (Err.Number <> 0)
End Function ' RunningInIde
I wrote something like this awhile back and can't find it, and needed it again. So I just wrote it again and I think I got it right:
Public Function IsRunningInIde() As Boolean
Static bFlag As Boolean
bFlag = Not bFlag
If bFlag Then Debug.Assert IsRunningInIde()
IsRunningInIde = Not bFlag
bFlag = False
End Function
No errors getting raised.
No resetting of Err.
Just one function.
Line 1: The "Static" declaration of "bFlag" causes the value of bFlag to stick across multiple calls to "IsRunningInIde". We want this because I call this function within itself, and I didn't want to litter the function with input parameters that aren't needed by the user.
Line 3: The "Debug.Assert" doesn't get called when not running in the IDE. So only when in the IDE does "IsrunningInIde" get called recursively.
Line 2: If not in the recursive call, bFlag starts out false, and gets set to true. If in the recursive call (only happens when running in the IDE), it starts out as true, and gets set back to false.
Line 3: Only call "IsRunningInIde" if it isn't already in this function recursively, by checking if bFlag is true.
Line 4: If in recursive call, always returns True, which doesn't really matter, but doesn't cause the Assert to fail. If not in recursive call, then returns "Not bFlag", which bFlag is now "False" if IsRunningInIde was called recursively, and bFlag is "True" if not called recursively. So basically, Not bFlag returns "True" if it is running in the IDE.
Line 5: Clears the bFlag so that it is always "False" at the beginning of the next call to this function.
It's hard to explain, it is better to step through it in your mind, in both scenarios.
If you want simpler to understand code, don't use it.
If there is a problem with this code, I apologize and let me know so I can fix it.