DLL in VB6 to VBA

DLL in VB6 to VBA

seabrahenrique
Advocate Advocate
2,602 Views
7 Replies
Message 1 of 8

DLL in VB6 to VBA

seabrahenrique
Advocate
Advocate

Hello guys,

 

I am trying to improve the security of a dvb project I have and I would like to turn the VBA code into a dll.

 

For now I will not migrate it to .NET so I have tried to make the DLL in VB6.

 

I was able to create it very easily and use it in VBA for Excel ...

 

But in AutoCAD it returns this message:

 

aaaa.png

(unregistered class, in english)

 

Note that the dll is loaded normally in autocad, until I can see the functions that I create in VB6 from it, see:

 

bbbb.png

 

But when running with f5, the error message is returned...

 

Any ideas?

 

PS: I already registered the DLL via cmd in all possible ways.

0 Likes
Accepted solutions (1)
2,603 Views
7 Replies
Replies (7)
Message 2 of 8

norman.yuan
Mentor
Mentor

Which version of AutoCAD you are using? 32-bit or 64-bit?

 

I bet you are using 64-bit AutoCAD of version AutoCAD2014 or later (who is still using 32-bit AutoCAD these days?).

 

VB6 can only create 32-bit DLLs. So, it works with your Excel, because it is very from likely 32-bit Office suite. It would only work with AutoCAD2013 (32 or 64 bit, because Acad VBA then was 32-bit only), or 32-bit AutoCAD of 2014 - 2018 (no more 32-bit AutoCAD since 2019).

 

I would not waste time using VB6 to build 32-bit DLL for AutoCAD, unless I stuck with very old 32-bit AutoCAD for long time to come.

 

Norman Yuan

Drive CAD With Code

EESignature

0 Likes
Message 3 of 8

seabrahenrique
Advocate
Advocate

My Autocad is 2016, 64 bit

 

You are right.

 

I considered this (about the vb6 dll being only 32bit).

But I confess that I didn't want to believe it and look for another solution, hehe ..

 

Thanks for the answer!

0 Likes
Message 4 of 8

seabrahenrique
Advocate
Advocate
Accepted solution

Hello programming friends.

 

I got a solution for this case that I thought should be shared.

 

Instead of creating a pure DLL, I created an ActiveX exe from VB6, see:

 

solution.png

 

The generated file can be referenced in VBA perfectly, and because it is executed "out of autocad" it is compiled on its own which makes Autocad work even with 64 bit and its constitution in 32.

 

Even though it is an old language, and most of us are migrating to .NET, I think the solution can still help anyone who has code remaining in VBA.

 

🙂

0 Likes
Message 5 of 8

norman.yuan
Mentor
Mentor

When you use COM exe to communicate with AutoCAD, you are running 2 applications (that is, the EXE must be running in order for the VBA code in AutoCAD to reach it), as you already know that it is "out of AutoCAD process".

 

If your purpose is to hide most your AutoCAD centric VBA code into the external EXE, other than business workflow requirements, which make ruuning external app to interact AutoCAD necessary, for example, running Excel to contrl AutoCAD, then this is rather bad practice:

 

1. the AutoCAD VBA code execution will take huge hit, like slowing down 10s of hundreds of times.

for example, you have a sub in AutoCAD VBA like:

 

Public Sub DoWork()

  Dim ent As AcadEntity

  For Each ent In ThisDrawing.ModelSpace

    '' Do something with each entity

    '' ...code details here

  Next

End Sub

 

Now you want to hide the VBA code showing what is to do with the entity, you now do:

Public Sub DoWork()

  Dim ent As AcadEntity

  For Each ent In ThisDrawing.ModelSpace

    Call MyExeServer.DoSomethingWithEntity(ThisDrawing, ent)

  Next

End Sub

 

If the drawing has tens of thousands entities in it, for each entity process, AutoCAD has to start communicating with the exe app many times, depending what the DoSomethingWithEntity() does, but since it is very likely doing AutoCAD related stuff, that method alone executed in the EXE would need to communicate with AutoCAD back and forth many time. Thus, the VBA code execution in AutoCAD could easily slow down from a few seconds to minutes.

 

2. Running extra app for a simple task 

3. The exe still need to be registered as COM component, thus the extra burden for every computer that need to run your "simplified" AutoCAD VBA code. Not to mention, it is very likely the EXE COM component is very likely break its version compatibility because of constant bug fixing or functionality updating, thus being required for re-registering.

 

Again, in my view, it is hardly worth doing things this way. 

 

Norman Yuan

Drive CAD With Code

EESignature

0 Likes
Message 6 of 8

seabrahenrique
Advocate
Advocate

I understand and thank you for the complement of the reply @norman.yuan 

 

I haven't really done more complex tests yet to understand the impact of this...

 

However, I have a counterpoint to the first example:

 

If instead of calling the exe code at each interaction of my 'For each' I start the EXE and all the interactions between AutoCAD elements are inside it.

It would be like packing all the necessary code inside the exe instead of calling it for each for each interaction.

(I don't know if I managed to get the idea across)

 

Anyway, as I said above, I understand that this is not the most elegant and optimized solution in the world, hehe.

But I have VBA code that needs to be protected before I migrate to .NET and in addition to the default password of the .DVB file, creating a DLL with the code is the only way I know to improve this protection 😕

 

I am open to different ideas!

Thanks again 🙂

0 Likes
Message 7 of 8

norman.yuan
Mentor
Mentor

@seabrahenrique wrote:

.. ..

 

However, I have a counterpoint to the first example:

 

If instead of calling the exe code at each interaction of my 'For each' I start the EXE and all the interactions between AutoCAD elements are inside it.

It would be like packing all the necessary code inside the exe instead of calling it for each for each interaction.

(I don't know if I managed to get the idea across)

 

... ...


That is wrong: the EXE is not AutoCAD, knows nothing about any object in AutoCAD process. It only hold referneces to the AutoCAD objects in AutoCAD process. When the code executes, the EXE has to send execution instruction with the references back to AutoCAD, if the execution is AutoCAD related (likely, most code would be AutoCAD related, I'd imagine, as long as the line of code refers to AutoCAD class/method...). You can imagine how much communication between AutoCAD and the external EXE. 

 

The EXE cannot work like black box package: takes all inputs, processes them and gives result out, because it is AutoCAD, it cannot manipulate AutoCAD objects (unless your EXE is developed with RealDwg technology - a customized "AutoCAD"!).

 

If I were you, I would definitely not waste time on this, just for keeping VBA code from being seen. I would also say that even spend time on VBA would on serious development is not very good route to follow at this time around.

 

Norman Yuan

Drive CAD With Code

EESignature

0 Likes
Message 8 of 8

seabrahenrique
Advocate
Advocate

There are whole codes made in VBA for Excel that manipulate Autocad.

As well as Autocad codes that manipulate information in Excel.

Both referring only to the appropriate object libraries.

 

Would it be so bad for an EXE to handle Autocad since it is using the same library?

 

Once again I say that I did not do more complex tests for the case ... But I see it as a possible solution to the problem in question.

 

I will draw better conclusions when I pass the code. (At least a part of it to test)

0 Likes