Multilanguage Debugging in VC IDE and VB IDE
| Author |
Message |
|
Hugh Clark
#1 / 3
|
 Multilanguage Debugging in VC IDE and VB IDE This is a multi-part message in MIME format.
------=_NextPart_000_0005_01BCF4E3.778241B0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
Any help on this would be greatly appreciated (sorry about the length!).
After reading Robert Schmidt's article in MSJ (May 97) I have tried =
following his instructions to debug an application in both the VB5 IDE =
and the VC5 IDE (Visual Studio 97 Enterprise).
I have a DLL, written in C, compiled by Developer Studio, from which I =
call functions in my VB ActiveX control. I have added VB5.EXE as the =
executable for a debug session to my settings for the C DLL, as well as =
the VB Project group directory to the "Working Directory" and the =
project group as the program argument.
This is all to the MSJ specifications.
When I start a debug session in VC, it launches VB5 as a child and =
allows me to set breakpoints in the VB code. The problem is, that when I =
try to step into the lines where I call the DLL functions, the calls are =
STILL opaque and it steps over, just as it would if I ran it =
stand-alone. I have even (in desperation) tried setting breakpoints =
inside the VC IDE inside the called functions.
When I stop the debug session in VB, VB remains running. According the =
the MSJ article, stopping the VB debugging should return control to VC =
who closes my VB container application and VB itself. When I explicitly =
exit it, the debug session in VC ends.
Has anyone out there had any experience in debugging in both IDE's? Can =
anyone shed any light on this?
There are a lot of differences between my applications and Robert =
Schmidt's in MSJ. He is using an ATL/COM application written in C++ with =
IDL files present. (Although the IDL files should have no bearing on =
this unless I am trying to debug solely in VB (I think?)) I am using a C =
DLL. He also uses a simple vbp which front-ends onto a SQL database as =
his argument in the VC IDE Settings - I'm using a vb group which =
contains my ActiveX stuff and a test container for the activeX control. =
But I can't believe that any of this should affect the debugging. It's =
merely a variation on a theme. I think (?!?.... I hope!).
Frustated and Confused,
Thanks in advance
Hugh
------=_NextPart_000_0005_01BCF4E3.778241B0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.71.1712.3"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Hi,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT size=3D2>Any help on =
this would be=20
greatly appreciated (sorry about the length!).</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>After reading Robert Schmidt's =
article in MSJ=20
(May 97) I have tried following his instructions to debug an application =
in both=20
the VB5 IDE and the VC5 IDE (Visual Studio 97 Enterprise).</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>I have a DLL, written in C, compiled =
by=20
Developer Studio, from which I call functions in my VB ActiveX control. =
I have=20
added VB5.EXE as the executable for a debug session to my settings for =
the C=20
DLL, as well as the VB Project group directory to the "Working=20
Directory" and the project group as the program =
argument.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>This is all to the MSJ=20
specifications.</FONT></DIV>
<DIV><FONT size=3D2>When I start a debug session in VC, it launches VB5 =
as a child=20
and allows me to set breakpoints in the VB code. The problem is, that =
when I try=20
to step into the lines where I call the DLL functions, the calls are=20
<STRONG><EM>STILL</EM></STRONG> opaque and it steps over, just as it =
would if I=20
ran it stand-alone. I have even (in desperation) tried setting =
breakpoints=20
inside the VC IDE inside the called functions.</FONT></DIV>
<DIV><FONT size=3D2>When I stop the debug session in VB, VB remains =
running.=20
According the the MSJ article, stopping the VB debugging should return =
control=20
to VC who closes my VB container application and VB itself. When=20
<STRONG>I</STRONG> explicitly exit it, the debug session in VC=20
ends.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>Has anyone out there had any experience in debugging =
in both=20
IDE's? Can anyone shed any light on this?</FONT></DIV>
<DIV><FONT size=3D2>There are a lot of differences between my =
applications and=20
Robert Schmidt's in MSJ. He is using an ATL/COM application written in =
C++ with=20
IDL files present. (Although the IDL files should have no bearing on =
this unless=20
I am trying to debug solely in VB (I think?)) I am using a C DLL. He =
also uses a=20
simple vbp which front-ends onto a SQL database as his argument in the =
VC IDE=20
Settings - I'm using a vb group which contains my ActiveX stuff and a =
test=20
container for the activeX control. But I can't believe that any of this =
should=20
affect the debugging. It's merely a variation on a theme. I think =
(?!?.... I=20
hope!).</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>Frustated and Confused,</FONT></DIV>
<DIV><FONT size=3D2>Thanks in advance</FONT> </DIV>
<DIV><FONT size=3D2>Hugh</FONT> </DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV></BODY></HTML>
------=_NextPart_000_0005_01BCF4E3.778241B0--
|
| Sun, 07 May 2000 03:00:00 GMT |
|
 |
|
WIlliam Ritchott
#2 / 3
|
Multilanguage Debugging in VC IDE and VB IDE --------------C8ECF5E5E027B8FB0384010F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
If you create an exe in vb5.0 the only thing you are doing in vc++ is
using the de{*filter*}, it is not the same as the one in vb, the one in vb
is used during a developement runtime, not during an exe runtime. If you
remember your c programming and I am sure you do. You have to compile as
an act of just trying the program whether or not you are in dev stage or
not. And in C to make an exe you have to link it to the outside world.
So your vb exe will go through the de{*filter*} and if there are no errors
then it will shut right down immediately.
Quote:
> Hi,Any help on this would be greatly appreciated (sorry about the
> length!). After reading Robert Schmidt's article in MSJ (May 97) I
> have tried following his instructions to debug an application in both
> the VB5 IDE and the VC5 IDE (Visual Studio 97 Enterprise).I have a
> DLL, written in C, compiled by Developer Studio, from which I call
> functions in my VB ActiveX control. I have added VB5.EXE as the
> executable for a debug session to my settings for the C DLL, as well
> as the VB Project group directory to the "Working Directory" and the
> project group as the program argument.This is all to the MSJ
> specifications.When I start a debug session in VC, it launches VB5 as
> a child and allows me to set breakpoints in the VB code. The problem
> is, that when I try to step into the lines where I call the DLL
> functions, the calls are STILL opaque and it steps over, just as it
> would if I ran it stand-alone. I have even (in desperation) tried
> setting breakpoints inside the VC IDE inside the called functions.When
> I stop the debug session in VB, VB remains running. According the the
> MSJ article, stopping the VB debugging should return control to VC who
> closes my VB container application and VB itself. When I explicitly
> exit it, the debug session in VC ends. Has anyone out there had any
> experience in debugging in both IDE's? Can anyone shed any light on
> this?There are a lot of differences between my applications and Robert
> Schmidt's in MSJ. He is using an ATL/COM application written in C++
> with IDL files present. (Although the IDL files should have no bearing
> on this unless I am trying to debug solely in VB (I think?)) I am
> using a C DLL. He also uses a simple vbp which front-ends onto a SQL
> database as his argument in the VC IDE Settings - I'm using a vb group
> which contains my ActiveX stuff and a test container for the activeX
> control. But I can't believe that any of this should affect the
> debugging. It's merely a variation on a theme. I think (?!?.... I
> hope!). Frustated and Confused,Thanks in advanceHugh
--------------C8ECF5E5E027B8FB0384010F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <HTML>
<BODY BGCOLOR="#FFFFFF">
If you create an exe in vb5.0 the only thing you are doing in vc++ is using
the de{*filter*}, it is not the same as the one in vb, the one in vb is used
during a developement runtime, not during an exe runtime. If you remember
your c programming and I am sure you do. You have to compile as an act
of just trying the program whether or not you are in dev stage or not.
And in C to make an exe you have to link it to the outside world.
<BR>So your vb exe will go through the de{*filter*} and if there are no errors
then it will shut right down immediately.
<BLOCKQUOTE TYPE=CITE> <FONT SIZE=-1><FONT COLOR="#000000">Hi,</FONT>Any
help on this would be greatly appreciated (sorry about the length!).</FONT>
<FONT SIZE=-1><FONT COLOR="#000000">After reading Robert Schmidt's article
in MSJ (May 97) I have tried following his instructions to debug an application
in both the VB5 IDE and the VC5 IDE (Visual Studio 97 Enterprise).I have
a DLL, written in C, compiled by Developer Studio, from which I call functions
in my VB ActiveX control. I have added VB5.EXE as the executable for a
debug session to my settings for the C DLL, as well as the VB Project group
directory to the "Working Directory" and the project group as the program
argument.This is all to the MSJ specifications.</FONT>When I start a debug
session in VC, it launches VB5 as a child and allows me to set breakpoints
in the VB code. The problem is, that when I try to step into the lines
where I call the DLL functions, the calls are <B><I>STILL</I></B> opaque
and it steps over, just as it would if I ran it stand-alone. I have even
(in desperation) tried setting breakpoints inside the VC IDE inside the
called functions.When I stop the debug session in VB, VB remains running.
According the the MSJ article, stopping the VB debugging should return
control to VC who closes my VB container application and VB itself. When
<B>I</B> explicitly exit it, the debug session in VC ends.</FONT> <FONT SIZE=-1>Has
anyone out there had any experience in debugging in both IDE's? Can anyone
shed any light on this?There are a lot of differences between my applications
and Robert Schmidt's in MSJ. He is using an ATL/COM application written
in C++ with IDL files present. (Although the IDL files should have no bearing
on this unless I am trying to debug solely in VB (I think?)) I am using
a C DLL. He also uses a simple vbp which front-ends onto a SQL database
as his argument in the VC IDE Settings - I'm using a vb group which contains
my ActiveX stuff and a test container for the activeX control. But I can't
believe that any of this should affect the debugging. It's merely a variation
on a theme. I think (?!?.... I hope!).</FONT> <FONT SIZE=-1>Frustated and
Confused,Thanks in advanceHugh</FONT></BLOCKQUOTE>
</BODY>
</HTML>
--------------C8ECF5E5E027B8FB0384010F--
|
| Mon, 08 May 2000 03:00:00 GMT |
|
|
|
Hugh Clark
#3 / 3
|
Multilanguage Debugging in VC IDE and VB IDE This is a multi-part message in MIME format.
------=_NextPart_000_0014_01BCF659.B6FCE300
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Ehmm...., yeah..... but I don't think you get my question.
What Microsoft claims is that whilst debugging in VB, stepping INTO a C =
function for which you have the source code should transfer control to =
the C de{*filter*}, and allow you to debug the C code. Once that function =
ends, control is transferred back to the VB de{*filter*}. (This is assuming =
you set everything up correctly, which I believe I have - see my =
original post).
If you can you should have a read at Robert Schmidt's article in MSJ =
("Investigating Multilanguage Debugging and the New IDEs of Visual =
Studio 97" - May 1997). It's quite good but I can't get to work what =
Microsoft and Robert Schmidt claim.
If you create an exe in vb5.0 the only thing you are doing in vc++ =
is using the de{*filter*}, it is not the same as the one in vb, the one in =
vb is used during a developement runtime, not during an exe runtime. If =
you remember your c programming and I am sure you do. You have to =
compile as an act of just trying the program whether or not you are in =
dev stage or not. And in C to make an exe you have to link it to the =
outside world.=20
So your vb exe will go through the de{*filter*} and if there are no =
errors then it will shut right down immediately. =20
=20
Hi,Any help on this would be greatly appreciated (sorry about the =
length!). After reading Robert Schmidt's article in MSJ (May 97) I have =
tried following his instructions to debug an application in both the VB5 =
IDE and the VC5 IDE (Visual Studio 97 Enterprise).I have a DLL, written =
in C, compiled by Developer Studio, from which I call functions in my VB =
ActiveX control. I have added VB5.EXE as the executable for a debug =
session to my settings for the C DLL, as well as the VB Project group =
directory to the "Working Directory" and the project group as the =
program argument.This is all to the MSJ specifications.When I start a =
debug session in VC, it launches VB5 as a child and allows me to set =
breakpoints in the VB code. The problem is, that when I try to step into =
the lines where I call the DLL functions, the calls are STILL opaque and =
it steps over, just as it would if I ran it stand-alone. I have even (in =
desperation) tried setting breakpoints inside the VC IDE inside the =
called functions.When I stop the debug session in VB, VB remains =
running. According the the MSJ article, stopping the VB debugging should =
return control to VC who closes my VB container application and VB =
itself. When I explicitly exit it, the debug session in VC ends. Has =
anyone out there had any experience in debugging in both IDE's? Can =
anyone shed any light on this?There are a lot of differences between my =
applications and Robert Schmidt's in MSJ. He is using an ATL/COM =
application written in C++ with IDL files present. (Although the IDL =
files should have no bearing on this unless I am trying to debug solely =
in VB (I think?)) I am using a C DLL. He also uses a simple vbp which =
front-ends onto a SQL database as his argument in the VC IDE Settings - =
I'm using a vb group which contains my ActiveX stuff and a test =
container for the activeX control. But I can't believe that any of this =
should affect the debugging. It's merely a variation on a theme. I think =
(?!?.... I hope!). Frustated and Confused,Thanks in advanceHugh
=20
------=_NextPart_000_0014_01BCF659.B6FCE300
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.71.1712.3"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Ehmm...., yeah..... but I don't =
think you get my=20
question.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT size=3D2>What Microsoft =
claims is=20
that whilst debugging in VB, stepping INTO a C function for which you =
have the=20
source code should transfer control to the C de{*filter*}, and allow you to =
debug=20
the C code. Once that function ends, control is transferred back to the =
VB=20
de{*filter*}. (This is assuming you set everything up correctly, which I =
believe I=20
have - see my original post).</FONT></DIV>
<DIV><FONT size=3D2>If you can you should have a read at Robert =
Schmidt's article=20
in MSJ ("Investigating Multilanguage Debugging and the New IDEs of =
Visual=20
Studio 97" - May 1997). It's quite good but I can't get to work =
what=20
Microsoft and Robert Schmidt claim.</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
=
t;...</DIV>If=20
you create an exe in vb5.0 the only thing you are doing in vc++ is =
using the=20
de{*filter*}, it is not the same as the one in vb, the one in vb is used =
during=20
a developement runtime, not during an exe runtime. If you remember =
your c=20
programming and I am sure you do. You have to compile as an act of =
just=20
trying the program whether or not you are in dev stage or not. And =
in C to=20
make an exe you have to link it to the outside world. <BR>So your vb =
exe=20
will go through the de{*filter*} and if there are no errors then it will =
shut=20
right down immediately. =20
<BLOCKQUOTE TYPE =3D CITE> <FONT size=3D-1><FONT=20
color=3D#000000>Hi,</FONT>Any help on this would be greatly =
appreciated=20
(sorry about the length!).</FONT> <FONT size=3D-1><FONT=20
color=3D#000000>After reading Robert Schmidt's article in MSJ =
(May 97) I=20
have tried following his instructions to debug an application in =
both=20
the VB5 IDE and the VC5 IDE (Visual Studio 97 Enterprise).I have =
a DLL,=20
written in C, compiled by Developer Studio, from which I call =
functions=20
in my VB ActiveX control. I have added VB5.EXE as the executable =
for a=20
debug session to my settings for the C DLL, as well as the VB =
Project=20
group directory to the "Working Directory" and the =
project=20
group as the program argument.This is all to the MSJ=20
specifications.</FONT>When I start a debug session in VC, it =
launches=20
VB5 as a child and allows me to set breakpoints in the VB code. =
The=20
problem is, that when I try to step into the lines where I call =
the DLL=20
functions, the calls are <B><I>STILL</I></B> opaque and it steps =
over,=20
just as it would if I ran it stand-alone. I have even (in =
desperation)=20
tried setting breakpoints inside the VC IDE inside the called=20
functions.When I stop the debug session in VB, VB remains =
running.=20
According the the MSJ article, stopping the VB debugging should =
return=20
control to VC who closes my VB container application and VB =
itself. When=20
<B>I</B> explicitly exit it, the debug session in VC =
ends.</FONT> <FONT=20
size=3D-1>Has anyone out there had any experience in debugging =
in both=20
IDE's? Can anyone shed any light on this?There are a lot of =
differences=20
between my applications and Robert Schmidt's in MSJ. He is using =
an=20
ATL/COM application written in C++ with IDL files present. =
(Although the=20
IDL files should have no bearing on this unless I am trying to =
debug=20
solely in VB (I think?)) I am using a C DLL. He also uses a =
simple vbp=20
which front-ends onto a SQL database as his argument in the VC =
IDE=20
Settings - I'm using a vb group which contains my ActiveX stuff =
and a=20
test container for the activeX control. But I can't believe that =
any of=20
this should affect the debugging. It's merely a variation on a =
theme. I=20
think (?!?.... I hope!).</FONT> <FONT size=3D-1>Frustated and=20
Confused,Thanks in advanceHugh</FONT></BLOCKQUOTE> =20
</BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0014_01BCF659.B6FCE300--
|
| Tue, 09 May 2000 03:00:00 GMT |
|
| |
|
