Re: How to debug an ActiveX DLL
- From: "Tony Proctor" <tony_proctor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 25 Apr 2006 11:43:36 +0100
You don't even need the main application in the IDE Dag. Hence, you don't
need its source and it doesn't even have to be a VB app
Just loaded the VB project for the DLL into the IDE, set the 'project start'
properties to 'Wait for Components to be Created', and just run it. It will
then wait until the main application tries to instantiate one of its
The VB IDE messes with the registry, and is itself a sort of DCOM server. It
redirects the relevant entries for a component to vb6debug.dll, which then
relays calls, etc., back to the IDE session currently executing a p-code
copy of that component.
In fact, in the Debugging tab of the project properties, you can even
instruct it to run your main app whenever you want to debug the VB DLL. This
is what makes it possible to debug VB DLLs loaded by ASP, or the SQLServer
DTS tasks, or MMC snap-ins, etc. They're not really very different from the
"Dag Sunde" <me@xxxxxxxxxxxx> wrote in message
"Roy Lewallen" <w7el@xxxxxxxxx> skrev i meldingand
Jon Ripley wrote:
I have been searching for a few months for concrete advice on how to
debug an ActiveX DLL written in VB6. None of the advice I have seen
thefollowed so far has achieved anything and I'm hoping that someone here
will be able to point me to a resource or give me some instructions on
how to do what I need.
I have written a DLL called xyz.dll which is a plug in for a closed
source application called abc.exe. The plug in works fine except for a
few known cases where there is a runtime error 5, I know what routine
areerror occurs in but can glean no further information - such as which
statement is generating the error and what the state of the variables
toat the time of the error.
The only solution I can currently see, as no other solutions seem to
exist, is to rewrite from observation enough of abc.exe in VB as a form
in an exe version of my project so that I can interactively debug the
code. I'd rather not have to do this as I would have to spend several
weeks reengineering a lot of code from abc.exe.
There has to be a simpler way, but what is it?
I'm a real novice when it comes to ActiveX DLLs, but you might be able
rundo what I do. The DLLs I've made consist entirely of classes. I simply
temporarily add the classes to the main exe (in your case abc.exe) and
the exe in the environment.Open the ActiveX project in one instance of vb, and the application
in another instance of vb.
In the app, make sure the References points to the activeX's .vbp file,
and not the registered dll.
Now, set the breakpoints you need in the activeX source, and hit F5.
Switch to the vb-instance containing the application project and run it.
You can now singlestep and have breakpoints in both, and jump from the app
and into methods running in the other vb (activeX project)