Valhalla Legends Archive

I'm not sure if this was the best forum to post this, but it should be close enough.

On my bot, and potentially for other projects too, I'd like to move the lower-level (connection, hashing, packet parsing) components to C++.  I've created a base class (BnetBot) to use that can be extended as necessary.

However I'd then like to access these in Visual Basic 6.  What I was thinking of doing is creating "helper" functions to hide the fact that objects are in play.  For example, a bot_create() function could return a pointer to a BnetBot object.  Then others like bot_say(), bot_set_join_handler(), etc. all accept a BnetBot pointer as an argument.  I was thinking just declaring these in VB as ByVal Longs but that approach seems messy.

Any reccomendations for the best way to approach this?

As far as I know, there's no way to mix the two languages together.  There are other ways however to use functions you've created in C++ in your VB apps.  Look into creating an ocx/dll.

Quote from: Sargera on August 19, 2004, 10:00 PM
As far as I know, there's no way to mix the two languages together.  There are other ways however to use functions you've created in C++ in your VB apps.  Look into creating an ocx/dll.

I am going to be creating a DLL.  I'm asking for best practices and experiences in the design.

Creating wrapper functions for every member function call to the class isn't going to be fun or worthwhile.  You should look into exposing your class as a COM Object.

This page lists your three options:Exporting C++ Classes from a DLL (scroll down)

Quote from: K on August 19, 2004, 10:49 PMYou should look into exposing your class as a COM Object.

That might work, but the instructions on how to do so don't help me.  I'm using MS VC++ Express 2005 Beta (what a mouthful!).  Found something in the "Add Class" area called ATL COM+ 1.0 Component, but it doesn't seem to be functional.  Darn.

Basically I want something that's (a) simple and (b) stable.  Hunting around MSDN, exposing a COM interface doesn't seem to be simple.  In addition, I want this bot class to be cross-platform.

Wrappers might be the way to go, but then I'm worried about passing the pointers to VB on 64-bit systems, as I believe the pointers will be 64 bits but VB will be looking for a 32-bit integer.

I guess there's always the option of dumping VB entirely...

When I need to do that, I use the ATL COM DLL Wizard in VC++.  Can't speak for 2005 express, I use VC6 and VC7.  But there are lots of concepts you will want to learn before using COM.

Start out by creating a Win32 DLL, to call from VB.  When you export the functions, they must meet a certain calling convention.

extern "C" int __stdcall DoStuffInLibrary();

extern "C" int __stdcall DoStuffWithAFile( LPSTR FilePath );

and so on.

Just a minor addition to Grok's post: the extern "C" is necessary when you're using C++ and unnecessary (depending on compiler, even prohibited) if you're using strict C.  If you get errors about not finding the functions, you've probably omitted the extern declaration when you needed it.  If you get parser / syntax errors, it's possible you included the extern when compiling in C code and thereby confused your compiler.

Thanks for the replies.  I have previously worked with writing C++ DLL's and then calling them from Visual Basic.  I already know about the need to use the STDCALL calling convention, and extern "C" to prevent name-mangling.

However, this was working with Yobgul's BnetAuth source that I made some additions to.  What I'm trying to accomplish here is much more complex.  Here was the original plan:

1. VB app calls a DLL function to create a new bot reference.  Although this actually returns a pointer to a C++ object, VB app treats this as a Long.
2. VB app calls other functions to set information about the bot (e.g. username, password, server), which accept the pointer and perform the requested modifications of the object.
3. VB app passes several function pointer values to be used as callbacks for various events (i.e. onConnect, onJoin, onTalk).
4. VB app calls final DLL function to connect the bot.  This creates the socket, establishes the connection, spawn a new thread, and enters a receive loop.  The loop uses the callback functions defined in step 3 to notify the VB app of events.
5. VB app calls other functions as necessary, to do things like send messages, clan invitations, etc.
6. When finished, VB app calls a DLL function to disconnect the bot (which also stops the receive thread), and another to delete the object from memory.

My main concerns here are the thread<->thread interactions, mainly the callbacks to the VB app, but also possibly the VB->DLL calls to send data.  Seems to me like this is asking for trouble, and that there should be an extra step to prevent the whole setup from bursting into flames.  Any thoughts on that note, or other problems with the concept?

[edit]Oh, I almost forgot another thing: passing the pointers.  I imagine this could cause some spectacular crashes as well, like if the object is deleted and the VB app attempts to access it via the pointer.  Also I'm guessing this won't work at all on 64-bit versions of Windows, as the VB app will be expecting a 32-bit integer.[/edit]

Due to my lack of experience with VB, I can't really help you much.  But if you're fairly competent in C++, why not just use it instead of going through the trouble of your current plans?  Unless of course you're creating this dll for generic use...(or public/private distribution)

I tend to agree with Sargera; your proposed design puts so much of the work on the C++ code anyway, it wouldn't be much more trouble to just write the entire program in C++ and avoid VB, thereby avoiding the pitfalls you've outlined.  As an alternative (which is somewhat more ambitious than your design), consider having the bot implemented purely in C++, but with no UI other than a status socket.  Then have a free-standing VB app (run totally independently of the bot) which can connect to the status socket and supply your user interface.  By putting the two in separate processes with a socket between them, you guard against the pitfalls in your post.  Of course, it's a lot more work to do what I propose, but it's much more extensible.

Quote from: Kp on August 21, 2004, 01:24 AMAs an alternative (which is somewhat more ambitious than your design), consider having the bot implemented purely in C++, but with no UI other than a status socket.  Then have a free-standing VB app (run totally independently of the bot) which can connect to the status socket and supply your user interface.

Ooooh, I like the sound of that.  I just might do that.  Thanks.

Quote from: shadypalm88 on August 21, 2004, 10:55 AM

Quote from: Kp on August 21, 2004, 01:24 AMAs an alternative (which is somewhat more ambitious than your design), consider having the bot implemented purely in C++, but with no UI other than a status socket.  Then have a free-standing VB app (run totally independently of the bot) which can connect to the status socket and supply your user interface.

Ooooh, I like the sound of that.  I just might do that.  Thanks.

Even though you may have already decided a path, I will offer a counterargument.  Using VB is desirable if you want to quickly write a functional yet pretty GUI using controls.  As you know, this is done with almost no real effort.  You could continue with your previous development plan (VB and C++ interaction) if you were willing to learn COM, or more specifically, ATL.  Advanced Template Library can be used to write classes which work from Visual Basic and other COM-capable languages.

Quote from: Grok on August 21, 2004, 12:46 PMEven though you may have already decided a path, I will offer a counterargument.

Always welcome.

Quote from: Grok on August 21, 2004, 12:46 PMUsing VB is desirable if you want to quickly write a functional yet pretty GUI using controls.  As you know, this is done with almost no real effort.

Yes.  However, in the current setup, I've already begun to move away from controls where they don't seem "logical", e.g. the Winsock and Timer controls, and have been using API functions to accomplish the same things.

Quote from: Grok on August 21, 2004, 12:46 PMYou could continue with your previous development plan (VB and C++ interaction) if you were willing to learn COM, or more specifically, ATL.  Advanced Template Library can be used to write classes which work from Visual Basic and other COM-capable languages.

Yes, this is true.  However, the more I thought about the client-server model, the more I liked it.  This is partially because my (beta) version of the VC++ IDE doesn't seem to support the COM wizard and I would have to do that by hand, and also because I was under the impression that COM was on the way out and .NET is Microsoft's latest thing.  But the main reason is it opens up many more possibilites, ones beyond Windows.  I also use Mac OS X and there really just aren't any good bots for it that I've found (sorry, Kane!).  This design would allow me to just write a new front end for OS X.  Plus the possiblilites as a shell bot should be obvious.

Thanks to all who replied.  Your help is appreciated.