C++ DLL called from VB

[FrankTheFox]

Hi,

i want to write a DLL which is called from MS Access (VBA)or MS Excel (VBA).
First i place a class with public and private member. Next i place a second class with... Then i define simple Functions (not class related) to call from outside (VBA).
My Problem is if those functions will be called there is no information to what kind of class functions they will invoke to get data or other stuff (Not visible from the "VBA" point of view.
My questions:
Every Function call from outside has to create the class within the dll do some stuff and collect the data and destroy the class. I think this is an overhead.
To create functions "CreateOSInfo" which creates the COSInfo (c++) is error prone cause nobody knows what kind of function is related to one class.
Should i creates classes and if so how do i get this done...

...
class  COSInfo {
public:
	COSInfo(void);
	~COSInfo();
	//member section started
private:
	const char* m_OsNames[MAX_OS_NAMES];
	const char* m_FkNames[MAX_FK_NAMES];
        const char* OSVersionString;
public:
	void OSVersion();
	long OSVersionLength();
	
};

class XXXY{

};


class ZZZA{

};

COSInfo* OSInfo = NULL;
extern "C" ACCSYSTEM32_API void  __stdcall CreateOSInfoInstance(void);
extern "C" ACCSYSTEM32_API void  __stdcall Release(void);
extern "C" ACCSYSTEM32_API void  __stdcall RealOSVersionA(LPSTR lpOsVersion, int nMaxCount);
extern "C" ACCSYSTEM32_API void  __stdcall RealOSVersionW(LPWSTR lpOsVersion, int nMaxCount);

Explanation:
RealOSVersionA belongs to "COSInfo". So what if func1, func2 belongs to COSInfo". Do i have to put "If (OSInfo != NULL) OSInfo = new COSInfo();
in every exported function which runs internally COSInfo?
And func2, func5, which belongs to class XXXY and func11, func12 which belongs to class ZZZA. From the VBA point of view i have no idea which exported function runs which class. So i thinks forget this class stuff and do it without classes.

Greetz
Franky

[kbw]

CreateOSInfoInstance should return a handle that's passed to the other functions.

CreateOSInfoInstance creates an instance of COSInfo and returns the pointer as the handle.

Release takes the handle, reinterprets it as a COSInfo* and deletes it.

Presumably, the other functions just return data in the COSInfo.

[FrankTheFox]

Thanks for your reply,


after thinking about, i think that using classes in a DLL which is called by VB(VBA) works with only one class inside. If there are more classes it is very difficult to maintain class creation and deletion (from the outside ->VB/VBA).

I will illustrate the problem:


class1
-------func_1 -- function1(exported) function1
-------func_2 --
-------func_3 -- function2(exported) function2
. . . . . . . . . . . . . . .
-------func_k -- functionk(exported) functionk

________________DLL______________________VB/VBA


function1 will create the class, funktionk destroy it. Each function will call a class member variable constant or function.
But if there are more than one classes...

class1
-------func_1 -- function1Class1(exported) function1Class1
-------func_2 -- function2Class1(exported) function2Class1
-------func_3 -- function3Class1(exported) function3Class1
. . . . . . . . . . . . . . .

class2
-------func_1 -- function1Class2(exported) function1Class2
-------func_2 -- function2Class2(exported) function2Class2
-------func_3 -- function3Class2(exported) function3Class2

________________DLL______________________VB/VBA


You must know that function2Class1 has to be called after creating class1 with function1Class1 and
calling function2Class2 after creating class2 with function1Class2.
So i think this will let someone ran into problem working with the DLL or you have to use prefixes with your function names...
Using classes inside a DLL will make some things more comfortable but on the other side it will give some big problems.
So i don't know but for me i will remove the classes and put there simple function instead.


Imagine the prefixes "Class.." will not be there and "function1Class1", "function2Class1", "function3Class1", "function1Class2",...
got other names like "RealOSVersion", "GetLocale", "GetKeyboardLayout" you got no idea what kind of class will serve this internally.
So you have to check for each function "AssoziatedClass != NULL" everything is ok but if ""AssoziatedClass == NULL" you have to create the class and at the end you have to destroy it. I think this will be a little memory overhead.


Greetz
Franky

[kbw]

It's conventional to open a file when you begin to use it, can close it when you're done. That metaphore applies to almost every object, to the point where in Plan 9 every object is a file (even the mouse). I don't understand your concern.