For specific DLL encapsulation objects, please refer to Liu Yi's "DLL encapsulation and call object technology in Delphi" and the source code for the book.
I encountered some strange problems in the process of compiling DLLs using DELPHI. I will now list them for reference only:
1. The DLL project generated by DELPHI writes: ShareMem must be the first unit in your library's USES clause AND your PRoject's. It is mentioned here that both DLL projects and projects using the DLL need to reference the ShareMem unit.
It is best to add ShareMem units to the project, because in actual use, it is found that sometimes objects are passed between the project and the DLL to use. When the object has properties of STRING type, strange errors may occur.
2. Definition problem of calling DLL function:
When output in DLL: function ABC: IInterface;
Function calls are defined as follows in the program:
type
TFunc = function: IInterface; stdcall; //There is an extra stdcall
A strange error will occur, which should be defined as the same as the one defined in the DLL:
type
TFunc = function: IInterface;
3. When using the interface in the DLL, remember to set it to NIL before the object is released in the DLL after use;
4. Debugging DLLs in DELPHI: I often encounter the problem that I cannot add breakpoints when debugging DLLs. Check the settings in the DLL, whether the output path of the compiled DLL is the same as the main program path setting that calls the DLL, and should be an absolute path;
5. In "DLL Encapsulation and Calling Object Technology in Delphi", the main limitation of DLL on encapsulation objects is
?? 1. The application calling the DLL can only use the dynamic binding method of the object in the DLL
2. . .
3. . .
There seems to be no such restriction on how to use objects in the main program for DLLs, I wonder why?