Possible to debug a VB6 .OCX that is used by Ms Access

Hello to everybody
I have a Visual Basic 6 .ocx...nothing fancy just a picturebox that i paint some lines to create a chart
I use this on Access and it runs ...but i have no control regarding its execution...i want to fully debug it to examine its functionality and enhance it
Any ideas how to setup VB6 IDE , some years ago i had an ActiveX .dll consumed by another application but simply by indicating to start this application (that used the .dll) i would stop to the 1st breakpoint just fine... (maybe i forgot the process i have a lot of years since i dealt with something like that)
For now i am stuck using msgboxes but this is not handy...

You need VB6 installed and you need to source code of the OCX project.

Quote:

---

Originally Posted by Arnoutdv

You need VB6 installed and you need to source code of the OCX project.

---

I have both...now the question is how to debug it from Access
I need to somehow start Access and when i hit a button to start "interact" with the OCX to return me back to VB6 IDE

you need to debug it in vb6 so you can use a project group
you can automate access from vb6 to replicate as if run from access

Quote:

---

Originally Posted by westconn1

you can automate access from vb6 to replicate as if run from access

---

Can you share some info regarding this... i must say never heard about it....

Look at the Project Properties dialog in the IDE, the Debugging tab.

There you can tell VB what program to run when you debug. When that program tries to create an instance of your control VB will intercept that and run it within the IDE.

Lots more on this in the documentation. Even more if you ever took the VB6 courses from Microsoft and have the books from them.

Quote:

---

Originally Posted by dilettante

Look at the Project Properties dialog in the IDE, the Debugging tab.

There you can tell VB what program to run when you debug. When that program tries to create an instance of your control VB will intercept that and run it within the IDE.

Lots more on this in the documentation. Even more if you ever took the VB6 courses from Microsoft and have the books from them.

---

This is the procedure as remember but the problem is that when instruct in the debugging to execute Access it doesn't get back to IDE...

long time ago I found a gem on a forum, writed by Steve Edwards a developper of VB6... and make a lot of r&d on this... unfortunately i don't find a way to share with you on this forum the pdf i made of this ...
so i wil copy/past the most interesting parts of that said M. Edwardson on my next reply (it will make a forum in forum :) so don' be supprise ...

From: Steve Edwards (steve_online_at_microsoft.online.com)
Date: 03/29/04
• Next message: MikeD: "Re: Registry keys for my application"
• Previous message: Alex Ivanov: "Re: IDE debug problem"
• In reply to: Lou: "Challenge VB Question"
• Next in thread: Bob O`Bob: "Re: Challenge VB Question"
• Reply: Bob O`Bob: "Re: Challenge VB Question"
• Messages sorted by: [ date ] [ thread ]
________________________________________
Date: Mon, 29 Mar 2004 15:41:47 -0600

Hey Louie,
Have you seen this KB article on the subject?
241859 PRB: Can not Debug VB Control in VB Development Environment
with Some
http://support.microsoft.com/?id=241859
Officially this debug scenario is unsupported because the feature was never
fully implemented by the VS product team to be used by any processes other
than VB4.exe, VB5.EXE, VB6.EXE or IExplore.exe. VB was originally designed
to debug OCX controls in two manners. 1) A Program Group, and 2) Under
Internet Explorer. Debugging VB controls using an MFC container through an
out-of process manner like this had not been tested by the product team
because this was not in the original specifications for the product
First of all if you think about what your doing when you attempt to debug
your VB6 component like this is that the OCX is being hosted in the VB6 IDE
process (out-of-process) and not within your VC++ client's
process(in-process), so now every call has to be marshaled back and forth
between these two processes. This is not the ideal way to test and debug
your components which will be executed in-process during normal execution..
There are numerous scenarios where this may fail to work properly, and the
recommended method is to use VC++ or any other true Win32 debugger like
Windbg to debug your in-process VB components running in client application
which were written in a different language.
See Q166275 HOWTO: Debug a Native Code Visual Basic Component in VC++
(http://support.microsoft.com/support.../q166/2/75.asp)
However, if you are really feeling the need to debug your component like
this and are willing to accept the fact that this is not supported, you can
try the following. I can give no guarantees that this will work for you.,
but I did get it to work a long while back when this question came up
internally.
You basically just need to add your VC++ Client to the registry and specify
that it is a DebugControlContainer.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Visual
Basic\6.0\DebugControlContainers\[YOURCONTAINEREXE.EXE]
For my test I created a VB OCX which does a simple msgbox which I could test
with.
I then created a Dialog Based VC Client, and dropped the above control onto
the dialog, compiled the exe to MFCClient1.EXE
I then added the registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Visual
Basic\6.0\DebugControlContainers\MFCClient1.EXE
Set the MFCClient.EXE as the Start Program on the debugging tab in VB.
I then set a breakpoint on the MsgBox line in the VB source and pressed F5
in VB to begin debugging. The MFC application began, I pressed the button
and it stopped in breakmode in VB as expected.
This ran fine under NT4 and Win2k back when I tested it, I have not tried it
under XP or Win2k3 yet.
- good luck,
Steve Edwards - Visual Basic CPR team.

I hoppe that help you, like it was for me....

NB my scope was different than your...

thanks Thierry76..i will test it and let you know.
It will be very interesting to catch a view of this pdf...maybe a link via pm (unless you can't share it of other reasons)...thanks anyway