Home > Back-end >  Help C Builder2010 written application calls the DLL
Help C Builder2010 written application calls the DLL

Time:11-01

Everyone a great god, the small white for help, I written in cb2010 application, and the one period of treatment is being converted into a DLL, reconstruction after the completion of the program is running and completely normal, the problem is that involves calls the DLL, close the application process will not end, only in the task manager to kill process to end, for the operation does not involve the DLL method is called is no problem, you can normally closed, so feel the problem in the DLL is not properly released, so help you greatly, there is a problem I call and release? How should be revised? Score is not much, thank you!

Calls and release the code as follows (the idea is to call DLL only when needed, after each call to immediately release, but not of no, and a method for determining method from baidu reformed after :
 HINSTANCE Hdl; 
Newp_funpath=ExtractFilePath (Application - & gt; ExeName) + "Reload. DLL";
//define the function prototype
Hdl=: : LoadLibrary (newp_funpath c_str ());//load the DLL
If (Hdl!=NULL) {
Log_reason=(AnsiString __stdcall (*) (AnsiString,
) : AnsiString) : GetProcAddress call (Hdl, the "logreason");
//get function entry address
If (log_reason!=NULL) {
Newp_reason=log_reason (newp_dev_ip newp_log_source);
}
The else {
ShowMessage (" Reload. DLL read failure! Please check the application integrity!" );
}
Log_reason=NULL;
FreeLibrary (log_reason);//release the DLL
Log_reason=NULL;
Hdl=NULL;
: : FreeLibrary (Hdl);//release the DLL
The delete Hdl;


Attachment: DLL code:
 extern "C" __declspec (dllexport) AnsiString __stdcall logreason (AnsiString log_dev_ip, AnsiString logresource)//longitudinal alarm causes decision function 
{
AnsiString newp_func_inipath, newp_func_ws_dm newp_func_ws_n;
. Omitting the middle procedure code...
Newp_func_ado - & gt; Close ();//off temporarily created in the process of ado connection
Newp_func_ado - & gt; SQL - & gt; The Clear ();//to empty the SQL statement
The delete newp_func_ado; Delete the ado
}
Newp_func_dev_data_net_p return (newp_func_src_data_net_p + ", "+ +", "+ newp_func_dst_data_net_p +" "+ newp_func_logtype);//returns the string
}

CodePudding user response:

These three lines delete:
Log_reason=NULL;
FreeLibrary (log_reason);//release the DLL
Log_reason=NULL;

This release of the library belongs to brain rot: when you
Hdl=NULL;
: : FreeLibrary (Hdl);//release the DLL

CodePudding user response:

Two problems
1. The LoadLibrary, after the research function, can be directly FreeLibrray

AnsiString 2. Not recommended as a DLL parameters or return values to use, and use the standard type, such as char * note the local variable to return to the problem of invalid

The description of the c + + Builder:
//Important note about DLL memory management the when your DLL USES the
//the static version of the RunTime Library:
//
//If your DLL exports any functions provides that pass the String objects (or user-defined structs/
//classes containing nested Strings) as the parameter or the function results,
//you will need to add the library MEMMGR. LIB to both the DLL project and
//any other projects that use the DLL, You will also need to use MEMMGR. LIB
//if any other projects which use the DLL will be performing new or delete
//operations on any non - TObject - derived classes which are exported from the
//DLL. Adding MEMMGR. LIB to your project will change the DLL and its calling
//EXE 's to use the BORLNDMM. DLL as their memory manager. In these cases,
//the file BORLNDMM. DLL should be deployed along with your DLL.
//
//To get the using BORLNDMM. DLL, pass the string information using "char *" or
//ShortString parameters.
//
//If your DLL USES the dynamic version of the RTL, do not need to
//explicitly add MEMMGR. LIB as this will be done implicitly for you
//-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

CodePudding user response:

reference 1/f, play big shoot early nuclear response:
these three lines delete:
Log_reason=NULL;
FreeLibrary (log_reason);//release the DLL
Log_reason=NULL;

This release of the library belongs to brain rot: when you
Hdl=NULL;
: : FreeLibrary (Hdl);//release the DLL

I also know that NULL then release are not appropriate, but now I have a question is if I am not NULL first, then release, so the DLL cannot release the real... DLL call inside I all stopped all VCL, rewrite the DLL for the first time, so this really can't understand the , after I change the code to the following programs: : FreeLibrary (Hdl); This step can't walk, show the message 1 a, 2 they don't have a message:
 
//log_reason=NULL;
FreeLibrary (log_reason);//release the DLL
//log_reason=NULL;
//Hdl=NULL;
ShowMessage (" 1 ");//1 pops up
: : FreeLibrary (Hdl);//release the DLL//here is something wrong with...
ShowMessage (" 2 ");//2, there is no
The delete Hdl;
//Hdl=NULL;
//: : FreeLibrary (Hdl);//don't forget to call after the release of DLL

CodePudding user response:

refer to the second floor Behard response:

two problems1. The LoadLibrary, after the research function, can be directly FreeLibrray

AnsiString 2. Not recommended as a DLL parameters or return values to use, and use the standard type, such as char * note the local variable to return to the problem of invalid

The description of the c + + Builder:
//Important note about DLL memory management the when your DLL USES the
//the static version of the RunTime Library:
//
//If your DLL exports any functions provides that pass the String objects (or user-defined structs/
//classes containing nested Strings) as the parameter or the function results,
//you will need to add the library MEMMGR. LIB to both the DLL project and
//any other projects that use the DLL, You will also need to use MEMMGR. LIB
//if any other projects which use the DLL will be performing new or delete
nullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnull
  • Related