Reputation: 66703
When debugging a VB6 application, I have noticed that the VB6 IDE keeps any libraries loaded if they were used by the application being debugged. The library remains loaded between debugging sessions. This interferes with my debugging because unfortunately, one of our libraries (written in delphi) keeps state around in global variables and has significant initialization/termination logic.
Simplified example of the problem: I have a foo.dll
with a counter inside it. I access this counter with the following declares in VB6:
Public Declare Function GetCounter Lib "foo.dll" () As Long
Public Declare Function IncrementCounter Lib "foo.dll" () As Long
The problem in this case is that the counter is not reset when I start a new debugging session. I would rather not write application or library logic to take this "recycled library state" scenario into account. I want to be able to start a debugging session with a clean slate.
Currently I force a library unload by restarting the VB6 IDE. Is there a better way?
I have accepted AngryHacker's answer as I am now convinced that restarting vb6.exe is the only way to start a VB6 debugging session with a completely clean slate.
Upvotes: 2
Views: 1212
Reputation: 16348
You should look at a few things:
Upvotes: 0
Reputation: 61596
I've struggled with that for years back in the day, particularly when coding ActiveX DLLs for use with IIS sites.
The only real antidote I found was to keep the library loaded in a separate VB6 instance (assuming you have the control of the source). That way you could simply press the Stop button on the toolbar and the library would no longer be loaded.
Upvotes: 1