Mystery Exit VB after debug session

Hi,
I have the following problem when I am debugging my application.

My VB program is accessing functions from my own C++ DLL. Everything seems to work perfectly fine in debug mode. My functions are called and are doing exactly what they should do.
The problem is, when I close my debug session either by closing my application or by the STOP button, not only my applications closes but VB itself closes ! No error is shown at the time VB exits...
Can anybody help me because this is really annoying. Each time I test something I have to restart VB and load my project again (this is time consuming !!!!!!!!)

Thx already !!!!!!
Tom Verbruggen

Firstly you should avoid using the stop button as it just terminates execution without allowing whatever objects you have created to unload correctly.

Does your DLL do anything like subclassing a window? Remember that you must release all windows resources when you are done with them - including setting WndProc back to its precious settings etc.

Try just loading and unloading the DLL - does this crash VB? If not then one of your functions is not cleaning up after itself. If so, your DLL compile may be corrupt.

HTH,
D.

-------------------------------------------------
Ex. Datis: Duncan Jones
Merrion Computing Ltd
http://www.merrioncomputing.com

Hi!
I had a similar problem.
you shold use:
DoEvents

commands
after each time you use your DLL.
(that's REALLY ANNOYING ISN'T IT?!)

----------
The @host is everywhere!
----------

Thx for the tip but even with the DoEvents my VB keeps on exiting.....
Thx anyway...

Hi,

My DLL does not use subclassing of any kind. It is a DLL that acts as a buffer between a C++ DLL provided by an external company and our in house VB code. In fact the code in my DLL does not create any objects (I think...)

Here is my code...


#include "stdafx.h"
#include "enmcapi.h"

MMSG SwiftMsg;

BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
return true;
}

USHORT _stdcall VBENMAttach(USERID VBUserID, PASSWD VBPassWord, FUNCID VBFuncID)
{

USHORT ENMrc;

ENMrc = ENMAttach(VBUserID,VBPassWord,VBFuncID);

return ENMrc;

}





The DLL is created with MS Visual C++.

I declare the DLL as follows :



Declare Function VBENMAttach Lib "enmvbapi" (byval InUserId as string, byval InPassword as string, byval FuncId as string) as Integer





Question : Is there a command in VB to load the full DLL without calling any functions in particalur???

I can start stop my debug session without problems as long as I haven't accesses my DLL. Once accessed, vb exits when I stop my debug session....

You can use the LoadLibrary to load a DLL into your VB app without calling any function and the FreeLibrary call to unload it again.

Are the USERID, FUNCID and PASSWD data types Cstr (null terminated) or OLE BSTR strings?

D.

-------------------------------------------------
Ex. Datis: Duncan Jones
Merrion Computing Ltd
http://www.merrioncomputing.com

I tried the LoadLibrary and FreeLibrary functions...
Apparently, the load is going fine but when I free with the FreeLibrary command, VB exits.....

Regarding the declaration of USERID...
Here is the declaration



/*---------------------------------------------------------------------*/
/* UserID for Application */
/*---------------------------------------------------------------------*/
typedef UCHAR USERID[UIDlen+1];
typedef USERID *PUSERID;

/*---------------------------------------------------------------------*/
/* Password for Application */
/*---------------------------------------------------------------------*/
typedef UCHAR PASSWD[PWlen+1];
typedef PASSWD *PPASSWD;

/*---------------------------------------------------------------------*/
/* functionID of Application */
/*---------------------------------------------------------------------*/
typedef UCHAR FUNCID[FUNClen+1];
typedef FUNCID *PFUNCID;




.
So apparently there is still something wrong with my DLL...
Why does it work perfectly fine running the exec file ??? Do I have to set some kind of parameters for debugging ???

Thx !

Tom

Although the documentation insists that the return from DLLMain is ignored except in the THREAD_ATTACH case I would be wary of this. Try returning NULL rather than TRUE when the parameter in DLLMain is THREAD_DETACH.

HTH,
D.

-------------------------------------------------
Ex. Datis: Duncan Jones
Merrion Computing Ltd
http://www.merrioncomputing.com

Tried returning NULL but no change...
I've read in the documentation that the entry point DLL MAIN is optional..
What about leaving DLLMAIN out of my DLL???

Tom

It is my understanding that DLLMain is only optional for resource-only DLLs which yours isn't.

You could compile the DLL with the __DEBUG flag and see if it gives you any additional information but I'm pretty stumped as to the cause.

HTH,
D

-------------------------------------------------
Ex. Datis: Duncan Jones
Merrion Computing Ltd
http://www.merrioncomputing.com

I tried removing the DLLMAIN but still got the same result...

Can I put some kind of trace to see why he is throwing out the VB application ????

Tom

Could you repeat the LoadLibrary and FreeLibrary test with the third party DLL - does that work OK?

-------------------------------------------------
Ex. Datis: Duncan Jones
Merrion Computing Ltd
http://www.merrioncomputing.com

I tried with 2 DLL's from third party...
One works, the other does not...

I tried with the DLL delivered from our vendor and which is used in my own C++ DLL and that one gives the same result !
Then I tried with amddlg.dll (don't know what it does but that does not matter) and that worked fine ...

So it seems that the problem is pointing to the delivered DLL from the vendor...

Tom

Is it possible to ask the vendor to recompile your DLL with the latest version of the C++ libraries - there are known issues with older versions of the AfxDLLMain causing a memory leak which may have a bearing on your problem.

HTH,
D.

-------------------------------------------------
Ex. Datis: Duncan Jones
Merrion Computing Ltd
http://www.merrioncomputing.com

I'll ask... hope they will do it ...
Anyway THANKS VERY MUCH for the hints an tips so far !!!!!!
I have learned a lot in this discussion !

THX AGAIN !

Tom

Sorry, it worked on me.
Maybe it'll work if you put the DoEvents from both sides of the function/sub :0)

----------
The @host is everywhere!
----------

If the third party supplier will not fix their code, for whatever reason, you can get around this problem by calling a LoadLibrary on the DLL when your application starts and not calling the FreeLibrary until the very last thing your application does when it is shutting down. The program will still crash but nobody will notice, as they will be expecting it to close.
A loaded DLL will not cause any problems with your Declare... use of the DLL - in fact it will make that bit faster.

-------------------------------------------------
Ex. Datis: Duncan Jones
Merrion Computing Ltd
http://www.merrioncomputing.com