C++ DLL in VB - separate instances

Hi all...

I have a little problem I'm hoping to get some help with.

I have a dll written in VB for data access, but its been giving problems lately when installing it on older Windows OSs. So, I've rewritten the functionality into a C++ dll compiled with gcc / g++ on MinGW.

I've exported the functions and I import them in VB as such:

	__declspec (dllexport) BSTR  __stdcall GetVersionNumber()
		char VersionLabel[15] = {0};
		BSTR ReturnValue;
		sprintf(VersionLabel, "%u.%u.%u", VersionMajor, VersionMinor, VersionRevision);
		ReturnValue = SysAllocStringByteLen (VersionLabel , lstrlen(VersionLabel));
		return ReturnValue;

Open in new window

That gets compiled as such:

g++ -c -DDatabase_dll Database.cpp -I ../Utils -L . -lpq -L ../Utils -lUtils -lOleaut32

g++ -shared -o Database.dll Database.o -Wl,--add-stdcall-alias -L . -lpq -L ../Utils -lUtils -lOleaut32

Open in new window

and then in VB it gets imported like this:

Private Declare Function GetVersionNumber Lib "Database.dll" () As String

Open in new window

If I call GetVersionNumber (or any other function), it works 100% and I have no problems. Where the problem comes in is that the orginal Database.dll written in VB still exists, but all functionality was stripped out and replaced by calls to the C++ version.

Thus, the main apps which use the VB version are not affected by the change. They continue to call the VB dll as if it implemented the functions itself. The VB dll is now only a wrapper around the C++ dll.

The problem comes in when I need to call more than one instance of the dll at a time.


dim x as Database.classname
set x = new Database.classname

dim y as Database.classname
set y = new Database.classname

x.SQLQuery("SELECT * FROM Table1")
y.SQLQuery("SELECT * FROM Table2")

Open in new window

This does not result in 2 separate instances of the C++ dll being called. The VB dll seems to create only one instance of the C++ dll so, the query in object y overwrites the query in object x (or I guess it would be more correct to say that object y = object x).

Does anyone know how to solve this? Should I look into com, activex, etc? If so, any pointers on implementing that from a MinGW / gcc / g++ compiler?


Who is Participating?
JSMCMAuthor Commented:
Hi Sara,

Thanks for reply. Yes, you're correct, there are other calls for returning records, moving the recordset, checking for end of recordset etc.

I do understand what you're saying, and if I was writing a brand new app from the ground up it might be an excellent way to go. For now though I needed a quick fix, so this is what I've done and it seems to work beautifully:

As mentioned, the C++ dll is called from the VB dll (wrapper). The problem with VB dlls is that you can only set their instancing to multiuse, that is, one instance is created and reused. All I did was a I recompiled this dll as an ActiveX.exe. This does not affect my calling apps at all, and I can set its instancing to singleuse, ie, each time the apps use the new keyword, there is a new instance of the component.

Thanks for taking the time to answer anyway!
you probably use a global variable or global pointer for the results and have two calls to the (c++) dll. one to execute the select statement and a second to fetch the results, right?

if so, your second select call would destroy the results of the first cause the operation system has only one instance of the dll.

to come out of this, you need to use dynamic memory in the c++ dll and return a kind of transaction number to the select call. that number would be incremented with each call and serves as identifier when fetching the results. after you returned the results you could delete the dynamic memory.

JSMCMAuthor Commented:
Not sure if accepting my own solution is the correct way to close a question??
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.