Debugging VB6 DLL launched from Excel VBA Macro

[Darrel Miller]

Here is my problem scenario...

I have a VB6 ActiveX Dll that is running in the VB environment. I have an
Excel spreadsheet with VBA code that accesses the VB6 DLL. I have added the
reference to the .vbp of the ActiveX Dll. Sometimes I can get the macro to
execute properly and I can trace into the VB6 DLL no problem. Other times
nothing seems to work. The errors I get are various. Sometimes the VBA
just doesn't recognize a class in the dll, sometime it claims the dll has
returned an error. At the moment it is telling me that the login to my SQL
Server database is failing which is just bizarre. If I compile the DLL,
everything works just fine.

The VB6 DLL is using Project compatibility if that is of any relevance.

Anyone have any suggestions regarding how to get this working reliably?

Thanks,

Darrel Miller
Tavis Software Inc.

 

[Gary Chang[MSFT]]

Hi Darrel,

Currently I am looking for somebody who could help you on it. We will reply
here with more information as soon as possible.
If you have any more concerns on it, please feel free to post here.


Thanks for your understanding!

Best regards,

Gary Chang
Microsoft Community Support
--------------------
Get Secure! ¡§C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp
&SD=msdn

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------

 

[Peter Huang [MSFT]]

Hi Darrel,

First of all, I wants to confirm something with you.
Did the "Excel spreadsheet" mean one of the excel worksheet in the .xls
file?
Did you add the reference to the .vbp file in the excel vba editor's vba
project?

Based on my experience, the reference in the vba edior is for *.olb, *.tlb,
*.dll,*.exe, *.ocx,*.xls,*.xla.
Also the VBA code seems to run as a script file, but when it runs, it will
still be compiled into "VBA compiled code".

So I think it is better to reference the dll in the vba project directly.
Also the Binary compatibility will be better, if you did not change the
interface definition in the vb dll, because it will not change the GUID on
which COM highly based.

Hope this helps.

If you still have any concern, can you provide a simple reproduce sample
together with detailed reproduce steps?
Thanks!

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Darrel Miller]

Hi Peter,

The VBA subroutine that I have written is stored in the "ThisWorkbook"
object so I am presuming that it is accessible from any worksheet in the
..xls file. I really only use one worksheet, so for me .xls spreadsheet and
worksheet are synonymous.

If I look at the references in the Excel Visual Basic Editor, normally I see
the reference to my compiled DLL. However, if I open the Visual Basic
Project (.vbp) for my DLL and I run that project, Visual Basic will register
a temporary version of my COM objects. Then if I look in the references of
the Excel Visual Basic Editor I will see a reference to the .vbp file.
While you are running the Visual Basic project you can select Browse on the
Excel references form and select the .vbp and it will see it as a COM
library.

Referencing the DLL directly does work but it does not allow debugging of
the Visual Basic code. Binary compatibility is fine for DLL that is
maintenance mode where there are rarely any changes, but my DLL is
constantly being developed. To try and enfore binary compatibility would be
a major pain!

I will see what I can do to try and create an environment to reproduce the
problem.

Thanks,

Darrel

 

[Peter Huang [MSFT]]

Hi

Thanks for your quickly reply!

Based on my experience, the compiled code is more inclined to fast calling
and components maintaining.
If you wants to change the document frequent, I think a VBA code is more
suitiable, which is the advantage of the script language.
Actually vba will also do some specified compiled when running to improve
the performance.

If you still have any concern, please feel free to post here.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Yan-Hong Huang[MSFT]]

Hello Darrel,

I am reviewing the issue thread. How is everything going? If you have any
more concerns on the problem, please feel free to reply here and we will
follow up.

Thanks very much.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
-http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.as
p&SD=msdn

This posting is provided "AS IS" with no warranties, and confers no rights.