JSMCM
asked on
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:
That gets compiled as such:
and then in VB it gets imported like this:
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.
Eg,
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?
Thanks...
John
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;
}
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
and then in VB it gets imported like this:
Private Declare Function GetVersionNumber Lib "Database.dll" () As String
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.
Eg,
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")
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?
Thanks...
John
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Not sure if accepting my own solution is the correct way to close a question??
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.
Sara