Yeah, Yeah, Yeah, I know. Why would I want to do a thing like that. Well, I''m working on a project that a VB programmer friend of mine started. It''s an online RPG type thing and he''s doing Client/Server. My job is to make the graphics engine that it''ll use. So far we''ve had a bit of success useing an ActiveX control but that really isn''t cutting it anymore and I need a better way. So I though if I could expose some classes from my C++ DLL to a VB module I could get rolling again. Problem is I have no idea how to nor if it''s even possible. I''ve heard that VB''s ActiveX DLL can, but I don''t know what it is really nor do I know how to make one from MSVC if it''s even possible. I''m open to any and all suggestions. Thanks in advance.

~Tim the Enchanter~ Arthur: Ohh great enchanter, tell us, what is your name? Enchanter: Some call me Timmmmmm. Arthur: Tell us great enchanter, how to you make fire without flint and tinder? Enchanter: Silence! Monty Python:The Search For The Holy Grail

Hello...Tim..
Maybe I can answer your question. To use c++ .dlls with your visual basic engine I would suggest using COM (yah it sucks I know.) Component Object Model is what COM stands for if I''m not mistaken. What you end up doing is creating a component that implements interfaces. In your case you would be using a C++ class to make the component.
The dll will allow your VB program to create the component and then query for the interfaces you have defined. It is really a complex topic so I would suggest getting InsideCOM from Microsoft press. It goes over this exact thing. But basically onceyou have the component in the dll what you do is ask the dll to create the component. It will then do so and the next thing to do is to query that component for the specific interfaces that you need.


Random Task

Actually, you could just compile your class into a normal C++ DLL, and in VB you go to Project-Refrences, then hit Browse, and select your DLL. Should be smooth riding from there. Tell me if this works, by the way. I''ve never tried doing it with my C++ classes b4.

Thanks a million RandomTask and BeanDog. I never would have thought to goto a COM DLL. It seems that a COM DLL either acts just like or is the same thing as a VB ActiveX DLL.

I''ve got the DLL working so far and once I compile it I can just reference to it in VB after it''s been registered. Any DLL that contains TypeLibrary or whatever information can be referenced like that, but if you make a normall DLL with no TypeLibrary info then you can''t use it in VB. Believe me I tried, and I am still trying. I would like to put TypeLibrary info into a normal DLL I just don''t know how to expose an object with the ODL language.

This way I could do a conditional compilation with a static test container so I can debug with ease. I''m sure I can do this using the COM DLL code an lots of #ifdef stuff, but I would like just basic object declarations. So I can say Dim file As CSTDFile instead of Dim file as TESTLib.STDFile and so on. Plus COM DLL''s seem to be really picky about linking. If I link to one of my static libs by just adding it to the FileView it''ll work with a Debug Build but not a Release, but if I add the lib into the link tab in the project settings I''m ok. Anyways, if anyone knows how to generate an ODL file for a normal DLL it''d make my life a bit easier. Elsewise COM it is.

Thanks

~Tim the Enchanter~
Arthur: Ohh great enchanter, tell us, what is your name?
Enchanter: Some call me Timmmmmm.
Arthur: Tell us great enchanter, how to you make fire without flint and tinder?
Enchanter: Silence!
Monty Python:The Search For The Holy Grail

Ok I goofed a bit. There is no way to export classes directly without using COM/ActiveX. ODL compleetely threw me off guard, I thought it was a way to directly expose classes but it''s just a part of ActiveX. I''m still a bit confused, but I''m better now.

~Tim the Enchanter~
Arthur: Ohh great enchanter, tell us, what is your name?
Enchanter: Some call me Timmmmmm.
Arthur: Tell us great enchanter, how to you make fire without flint and tinder?
Enchanter: Silence!
Monty Python:The Search For The Holy Grail

VB ActiveX DLLs are actually COM DLLs, but I have it on a reasonably good authority that the implementation by Microsoft isn''t so hot...

As an example, write a method called AddRef, QueryInterface or Release in a class module - then try and run it....

Basically VB has reserved these method names because it uses them to expose the necessary COM stuff.

Writing a COM DLL using C++ specifically intended for VB is quite tricky if you want to do it yourself from scratch. You need to pay particular attention to a couple of interfaces - IUnknown and IDispatch (yuk).

Better off using something like ATL.

Thanks TPH. I''ve got it working ok now, fixed the link problems. I"m using the type of COM DLL that Appwizzard makes, I belive that''s ALT but thanks to MSDev I don''t have to worry about that much because it''s hidden behind ClassView.

This is a lot easier than I thought. I was thinking I would have to maintain a lot of crap manually.

~Tim the Enchanter~
Arthur: Ohh great enchanter, tell us, what is your name?
Enchanter: Some call me Timmmmmm.
Arthur: Tell us great enchanter, how to you make fire without flint and tinder?
Enchanter: Silence!
Monty Python:The Search For The Holy Grail

There is nothing wrong with VB ActiveX DLLS, especially for logic code. Its a hell of alot faster than alot of people give it credit for.

If down the road you run into a speed issue, then you can implement the object in C++ and likely have a drop in replacement for the original if you follow the same signatures.

Besides, there will be a bit of container functionality you will get for free coming from VB instead of C++ (collection/dictionary support).

Since it sounds like your already headed down the C++ path, stick with ATL as it does make COM development extremely easy compared to a raw COM implementation in C++.

Ok this is a bit odd. I''ve got MSVC exporting my class as an object and Visual Basic can see it just fine, but I''ve also created a control in the same DLL that''s intended to replace an ActiveX OCX and it''s not working.

The OCX control has the same members as the DLL one, but the DLL one fails whenever I try to call any of it''s functions. Even if all the function does is return S_OK.

I''m compleetely clueless why VB dosen''t like my Controls. Am I forgeting something that''s specific to the VB interface?

I know that this is a long shot, but if anyone has any idea what I''m doing wrong I''d be beyond thankfull.

~Tim the Enchanter~
Arthur: Ohh great enchanter, tell us, what is your name?
Enchanter: Some call me Timmmmmm.
Arthur: Tell us great enchanter, how to you make fire without flint and tinder?
Enchanter: Silence!
Monty Python:The Search For The Holy Grail

I am assuming that the DLL houses a COM object so what is the Err.Descpription or Err.Number after you try to use the object?

Using ATL to create COM objects in C++ then using the object from VB is a snap, once you get the hang of it.

From your ATL project (C++) have you inserted your new object? (Insert | Insert new ATL object ...). This process is bascially just adding a C++ class that will implement your COM interface that will be used from VB (After adding a Reference to it).