Interesting question, Jay Bee. I am going along the same lines. I just made my first dll for use in DBPro. I like it! I have some math routines to start...like the integer divide by power of 2 thing: it works nice, but the time across the interface is still a big factor in a routine that simply flips bits and shifts.
The standard VC++ appwizard-generated dll boilerplate code shows an example of how to export variables and classes from a dll. The odd thing is that DBPro does not make use of this mechanism...to my knowledge. They instead use a string table with the C++ decorated names of functions and variables. This is messy, and name-mangling is not at all standardized to my knowledge. It works well enough for functions, so...I am confident that I can add some of the functionality that I want in DBPro, BUT I AM ASKING MYSELF...what am I doing? I need DarkSDK if I want to do that. If you are using C++, I think it would be better to go with DarkSDK.
It will probably kill me here to say this, but...BASIC is not the language for too much OO coding. It falls down too quickly. Adding a DLL interface puts additional overhead into each call by its very nature. Also, you will need a mechanism to translate between types...most likely on the dll side for speed reasons. The introduction of DLL code into your app will necessitate inclusion of the dll into your app. (Maybe not a problem, I am only trying to relate why I feel that I should get DarkSDK.)
It seems to me that DBPro is moving in the right direction, but there are several waypoints to go...true indirection, casting, pass by reference, classes. Then you get into OO land with its messiness about inheritence, subclassing, etc. It is really a BIG leap.
You could conceivably write a dll that solved most of your woes with respect to UDTs, etc. It seems to me that it would grow into a bloated piece of code that was nearly impossible to debug effectively, and not really the OO plug-in that you are wanting.
...class include file...
#ifdef MYDBP_EXPORTS
#define MYDBP_API __declspec(dllexport)
#else
#define MYDBP_API __declspec(dllimport)
#endif
#include "globstruct.h"
class MYDBP_API MY_DBP
{
public:
GlobStruct* m_pDBProCore; // DBPro CORE pointer.
MY_DBP(LPVOID pCore);
~MY_DBP();
};
...class .cpp file
#include "stdafx.h"
#include "MYDBP.h"
MY_DBP* g_pMY_DBP = NULL;
#define MYCOMMAND __declspec (dllexport)
BOOL APIENTRY DllMain(HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_DETACH:
if (g_pMY_DBP != NULL)
{
delete g_pMY_DBP;
g_pMY_DBP = NULL;
}
case DLL_THREAD_DETACH:
case DLL_PROCESS_ATTACH:
case DLL_THREAD_ATTACH:
break;
}
return TRUE;
}
// DBPro calls this function when the dll is loaded. This is an
// exception to the rule of dll i/f with DBPro. It does look for
// a c function to pass the pointer to in the exports.
MYCOMMAND void ReceiveCoreDataPtr(LPVOID pCore)
{
if (g_pMY_DBP != NULL) delete g_pMY_DBP;
g_pMY_DBP = new MY_DBP(pCore);
}
MY_DBP::MY_DBP(LPVOID pCore)
{
m_pDBProCore = (GlobStruct*)pCore;
return;
}
MY_DBP::~MY_DBP()
{
//
}
Now, I hope that you realize what is going on, here...we are using C to wrap C++ for BASIC, which is hiding an API. Your interface from DBPro is not to the classes...it is to functions in C that you add like it says in the help topic "Third Party Commands". The C++ side is implemented by adding classes, their include files follow the include file for MYDBP. That exposes them to MYDBP, and to the C functions that you write in the cpp file above. It is interesting and fun. Now, you make it useful.
