topic Re: Debugging In-process ActiveX DLL in VBA Forum

Debugging In-process ActiveX DLL

Anonymous — Tue, 11 Jul 2000 12:32:28 GMT

I hope someone here can help me or point me in the right direction:

I am trying to transfer a suite of routines that I already wrote and
debugged in VBA to an activex dll. I am told this is the best way of
making a robust / secure and fast application in visual basic.

I am using VB5 enterprise edition to compile the activex dll.

I realize that one of the issues that I need to attend to is
initializing some of the objects that we get for free in vba
(thisdrawing for instance).

I have written a simple public class whose job will be to farm out the
work to the routines I have already written in standard .bas modules
and initialize the important objects globally at the module level..

My problem is that I have quite a bit of debugging to do mainly due to
the initialization of the thisdrawing object and others, and I can't
figure out how to get the debugging process working.

I have read the help on books online but it doesn't seem to be
applicable to the case where I am debbugging an in-process dll from an
already existing application. The best I understood - I would need
the acad.exe as well in the project group and I have no idea what that
means nor how to do it.

If anyone could help shed some light on this issue I would be most
obliged.

Thanks,
Natan Elsberg

Re: Debugging In-process ActiveX DLL

Anonymous — Tue, 11 Jul 2000 12:32:28 GMT

Hi Natan,
I know the feeling, 🙂 I recompiled my first DLL over 100 times before I
found out how to actively debug it. I am using VB6 Prof. and Acad R14, but
I think the following will still work for you.

-------------------------------------
ThisDrawing Object
-------------------------------------
There are several ways to set your reference to the AutoCAD drawing. The
way I do it is to create a function in my DLL, and pass the function a
reference to the current Drawing object from VBA. The function then sets a
global variable to the reference passed by AutoCAD VBA. This avoids all the
multi-session joys of GetObject. 🙂
- Note: If you set a global variable in your DLL to a reference to your
AutoCAD drawing, you MUST set the reference to nothing before unloading the
DLL. Otherwise AutoCAD will show you one of those neat Fatal Error...
messages. 😉

Public Sub SetDrawing(AcadDrawing As AcadDocument)
Set gDoc = AcadDrawing
End Sub

From the AutoCAD side, you can also create a wrapper function that returns a
reference to the DLL. This can make programming a little easier. I use the
following function to reference my DLL.

Public Function DLL() As ESD_Tools
On Error Resume Next
If gVB Is Nothing Then
Set gVB =
ThisDrawing.Application.GetInterfaceObject("ESDTools.ESD_Tools")
gVB.SetDrawing ThisDrawing
End If
Set DLL = gVB
If Err Then Call AlertAdmin(Err, "All_ESD_Functions.DLL()", "DLL may not be
installed")
End Function

If you do it like this, it only takes one line of code to call the DLL.
Just use the syntax: DLL.(FunctionName)
As you can see in the function, I am also setting a global variable to
reference the DLL from the AutoCAD VBA side. This allows me to show / hide
forms without closing them between calls to the DLL.
If you use this method, I would also suggest creating another function in
the DLL; one that will unload all forms and set the drawing's global
reference to nothing. You will need to call this function before unloading
the VBA project or closing AutoCAD.

-------------------------------------
Debugging the inprocess DLL
-------------------------------------
The following steps should allow you to actively debug your DLL in the
Visual Basic Editor.
1. With AutoCAD closed, open your DLL project.
2. In Visual Basic, click Start with Full Compile from the Run menu.
3. When there are no compile errors, and the DLL is running, start AutoCAD.
4. In AutoCAD VBA, go to tools --> References and add the reference to your
DLL.
5. Use a VBA procedure to call a function in your DLL.
Note: Modal forms in your DLL will act differently when running this way.
You may need to toggle to VB and click Break, Run in order to see the form.
If the DLL has an error, VB should stop and tell you. You can also use
breakpoints and other debugging features in your code. Just keep in mind
the fact that you have active references between Acad and VB and if you End
either process without clearing these variables, Acad will likely crash.

Are you confused yet? 🙂 It took me a while to figure this out, but it
sure has made it a lot easier to work with inprocess DLLs.

Have a great day!!

- Adam

P.S.
Make sure you frequently save your work, especially on the Acad side. 🙂

"Natan Elsberg" wrote in message
news:396b1127.17754469@discussion.autodesk.com...
> I hope someone here can help me or point me in the right direction:
>
> I am trying to transfer a suite of routines that I already wrote and
> debugged in VBA to an activex dll. I am told this is the best way of
> making a robust / secure and fast application in visual basic.
>
> I am using VB5 enterprise edition to compile the activex dll.
>
> I realize that one of the issues that I need to attend to is
> initializing some of the objects that we get for free in vba
> (thisdrawing for instance).
>
> I have written a simple public class whose job will be to farm out the
> work to the routines I have already written in standard .bas modules
> and initialize the important objects globally at the module level..
>
> My problem is that I have quite a bit of debugging to do mainly due to
> the initialization of the thisdrawing object and others, and I can't
> figure out how to get the debugging process working.
>
> I have read the help on books online but it doesn't seem to be
> applicable to the case where I am debbugging an in-process dll from an
> already existing application. The best I understood - I would need
> the acad.exe as well in the project group and I have no idea what that
> means nor how to do it.
>
> If anyone could help shed some light on this issue I would be most
> obliged.
>
> Thanks,
> Natan Elsberg
>
>

Re:

Anonymous — Tue, 11 Jul 2000 21:19:53 GMT

Hi guys,
I know the feeling as well. It's a good thing that Randall and the Llama
know thier dll's 🙂 The following is the example given to me on how to assign
and set a class property to the acad app. No need for getobject,
getinterfaceobject, ect.

Hi Josh,

Ok, lets look at a fast example:

Option Explicit

Private objAcad As AcadApplication

Public Property Set AcadApp(objApp As AcadApplication)
Set objAcad = objApp
End Property

Public Property Get AcadApp() As AcadApplication
Set AcadApp = objAcad
End Property

Public Function LayerExists(LayerName As String) As Boolean
Dim ThisDwg As AcadDocument
Dim Layr As AcadLayer
If Not Me.AcadApp Is Nothing Then
Set ThisDwg = Me.AcadApp.ActiveDocument
For Each Layr In ThisDwg.Layers
If UCase(Layr.Name) = UCase(LayerName) Then LayerExists = True
Next
End If
End Function

Now on the client end (in AutoCAD VBA):

Public Sub Test
Dim objMyDll As YourDll.CreatableObjectName 'The dll library and the class
name
Set objMyDll = New CreatableObjectName 'just the class here
Set objMyDll.AcadApp = Application
MsgBox objMyDll.LayerExists("layernamehere")
End Sub

Ta da

(
)
c[]
Randall Rath

In the client end you can also save a line of code by using:

Public Sub Test
Dim objMyDll As New YourDll.CreatableObjectName
Set objMyDll.AcadApp = Application
'your code here
End Sub
Adam Waller wrote:

-Josh

> Hi Natan,
> I know the feeling, 🙂 I recompiled my first DLL over 100 times before I
> found out how to actively debug it. I am using VB6 Prof. and Acad R14, but
> I think the following will still work for you.
>
> -------------------------------------
> ThisDrawing Object
> -------------------------------------
> There are several ways to set your reference to the AutoCAD drawing. The
> way I do it is to create a function in my DLL, and pass the function a
> reference to the current Drawing object from VBA. The function then sets a
> global variable to the reference passed by AutoCAD VBA. This avoids all the
> multi-session joys of GetObject. 🙂
> - Note: If you set a global variable in your DLL to a reference to your
> AutoCAD drawing, you MUST set the reference to nothing before unloading the
> DLL. Otherwise AutoCAD will show you one of those neat Fatal Error...
> messages. 😉
>
> Public Sub SetDrawing(AcadDrawing As AcadDocument)
> Set gDoc = AcadDrawing
> End Sub
>
> From the AutoCAD side, you can also create a wrapper function that returns a
> reference to the DLL. This can make programming a little easier. I use the
> following function to reference my DLL.
>
> Public Function DLL() As ESD_Tools
> On Error Resume Next
> If gVB Is Nothing Then
> Set gVB =
> ThisDrawing.Application.GetInterfaceObject("ESDTools.ESD_Tools")
> gVB.SetDrawing ThisDrawing
> End If
> Set DLL = gVB
> If Err Then Call AlertAdmin(Err, "All_ESD_Functions.DLL()", "DLL may not be
> installed")
> End Function
>
> If you do it like this, it only takes one line of code to call the DLL.
> Just use the syntax: DLL.(FunctionName)
> As you can see in the function, I am also setting a global variable to
> reference the DLL from the AutoCAD VBA side. This allows me to show / hide
> forms without closing them between calls to the DLL.
> If you use this method, I would also suggest creating another function in
> the DLL; one that will unload all forms and set the drawing's global
> reference to nothing. You will need to call this function before unloading
> the VBA project or closing AutoCAD.
>
> -------------------------------------
> Debugging the inprocess DLL
> -------------------------------------
> The following steps should allow you to actively debug your DLL in the
> Visual Basic Editor.
> 1. With AutoCAD closed, open your DLL project.
> 2. In Visual Basic, click Start with Full Compile from the Run menu.
> 3. When there are no compile errors, and the DLL is running, start AutoCAD.
> 4. In AutoCAD VBA, go to tools --> References and add the reference to your
> DLL.
> 5. Use a VBA procedure to call a function in your DLL.
> Note: Modal forms in your DLL will act differently when running this way.
> You may need to toggle to VB and click Break, Run in order to see the form.
> If the DLL has an error, VB should stop and tell you. You can also use
> breakpoints and other debugging features in your code. Just keep in mind
> the fact that you have active references between Acad and VB and if you End
> either process without clearing these variables, Acad will likely crash.
>
> Are you confused yet? 🙂 It took me a while to figure this out, but it
> sure has made it a lot easier to work with inprocess DLLs.
>
> Have a great day!!
>
> - Adam
>
> P.S.
> Make sure you frequently save your work, especially on the Acad side. 🙂
>
> "Natan Elsberg" wrote in message
> news:396b1127.17754469@discussion.autodesk.com...
> > I hope someone here can help me or point me in the right direction:
> >
> > I am trying to transfer a suite of routines that I already wrote and
> > debugged in VBA to an activex dll. I am told this is the best way of
> > making a robust / secure and fast application in visual basic.
> >
> > I am using VB5 enterprise edition to compile the activex dll.
> >
> > I realize that one of the issues that I need to attend to is
> > initializing some of the objects that we get for free in vba
> > (thisdrawing for instance).
> >
> > I have written a simple public class whose job will be to farm out the
> > work to the routines I have already written in standard .bas modules
> > and initialize the important objects globally at the module level..
> >
> > My problem is that I have quite a bit of debugging to do mainly due to
> > the initialization of the thisdrawing object and others, and I can't
> > figure out how to get the debugging process working.
> >
> > I have read the help on books online but it doesn't seem to be
> > applicable to the case where I am debbugging an in-process dll from an
> > already existing application. The best I understood - I would need
> > the acad.exe as well in the project group and I have no idea what that
> > means nor how to do it.
> >
> > If anyone could help shed some light on this issue I would be most
> > obliged.
> >
> > Thanks,
> > Natan Elsberg
> >
> >