Home > Back-end >  Encapsulation IndyTCP into the DLL and does not respond to events
Encapsulation IndyTCP into the DLL and does not respond to events

Time:10-19

Due to integration with other software, you need to write a DLL for communication, encapsulation TdTCPServer response onExecute and ondisconect events, not onConnect event can response, however, should be a thread problems, how to solve?

CodePudding user response:

Since writing a Dll, why still use to control, direct socket

CodePudding user response:

Do not use the VCL DLL, then you will know the pain, or you'll use BPL,

CodePudding user response:

Their encapsulation socket is too much trouble, too late time, steal a lazy, because this DLL is to other software (not written by Delphi) integrated use of, can't dozen become BPL,
Reason if there is not the main thread is the DLL, but events corresponding is call by the main thread, so there is no reflected the,,

CodePudding user response:

refer to the second floor sololie response:
do not use the VCL DLL, then you will know the pain, or you'll use BPL,
don't understand

CodePudding user response:

reference 4 floor budded response:
refer to the second floor sololie reply: do not use the VCL DLL, then you will know the pain, or you'll use BPL, confused

DLL Delphi object is very lengthy, try not to use the class

CodePudding user response:

reference 5 floor HSFZXJY reply:
reference 4 floor budded response: refer to the second floor sololie reply: do not use the VCL DLL, then you will know the pain, or you'll use BPL, confused
DLL Delphi object is very lengthy, try not to use class
well, can use the interface implementation

CodePudding user response:

Not repetitive, mainly Delphi for memory management method, can see the Delphi "in a nutshell", Chinese seem to call "the Delphi development guide",
I quote two paragraphs:

Using DLL, it must be the main dynamic memory, any memory should be assigned by the DLL DLL will be released after uninstalled, however, your application may retain a pointer to the block of memory, if do not pay attention, it may lead to worse access barriers or problems, the most simple solution is to put the ShareMem unit as the first unit in your application and it loads each repository, ShareMem unit all the memory requests to a separate DLL (BorlndMM. DLL), when the application runs it has been loaded, you can load or unload the DLL, and don't have to worry about the pointer hung,

.

ShareMem can solve the problem of A kind of memory, but not solve another: class identifier (classidentity), if the application and the DLL using the class A, Delphi can't judge the two modules are using the same class, although the two modules using the same class name, but this does not mean that these two classes is the same, the Delphi follow the safest route, assume that these two classes is not the same, even if you know more, but you also have no simple way to tell the Delphi,

Sometimes, have different labeling doesn't cause any problems, but if your program tried to cross the border of A DLL to use an object reference, it is and as the operator will not work in accordance with the way you expect, because DLL that class A and class A different application, is the operator will always return False,

One the way to avoid this problem is not beyond the boundary of the DLL transfer object, for example, you have a graphics object, but don't pass a TBitmap object, but is passed a handle to a Windows (HBITMAP) instead, another solution is to use package,

.

If you use the DLL and trying to between the DLL or transfer object between the application and the DLL, you will encounter a series of problems, first of all, each DLL or EXE keeps copies of itself to the class table, in the DLL or EXE passed between objects, is and the as operator does not work properly, use the package can solve this problem, another problem is the memory allocated in the DLL are owned by the DLL, when Windows unload the DLL, all by the DLL allocated memory is released, even if the EXE or another DLL retains the memory of a pointer is also so, in the use of string, dynamic array and the Variant, it will become a major problem, because you never know when the Delphi will automatically allocates memory,

Solution is ShareMem unit as your project and the first unit of each DLL, ShareMem unit to install a memory manager to point to all of a particular DLL -- BorlndMM. DLL memory allocation request, the application does not uninstall BorlndMM, until it exits, this kind of DLL magic is carried out in public, so you don't have to worry about the details, just make sure to use ShareMem unit, and make sure it is the first unit procedures and used by the library, and when you release to the customer or the consumer of your application, you need to BorlndMM. Include the DLL,

CodePudding user response:

Use interface, should be able to meet the requirements of you,
  • Related