COM programming
In-process COM servers (in-process COM server)
In-process COM server (in-process COM server) has been introduced briefly before, here, only some need to understand, understand the knowledge points, and then programming may be better; in-process servers are given this name because they are implemented within a DLL. As a result, the server occupies 擗 the same address space (process) as the application that uses it. All in-process COM servers output four standard functions: DllRegisterServer, DllUnregisterServer, DllGetClassObject, and DllCanUnloadNow. Literally, we've also been able to sense what the work of these functions will be. Of course, Delphi has provided us with the default implementations of these functions. As a result, readers do not have to write code to implement these functions, but they should understand exactly what they do.
²dllregisterserver. DllRegisterServer are invoked automatically in two ways. The IDE's Register ActiveX server menu option invokes it, and Windows command line Application RegSvr32.exe (or Borland application Tregsvr) also invokes it, in many cases directly with the Register ActiveX server to invoke, if manually to implement, you can write one. BAT file. Regardless of the way it is invoked, DllRegisterServer registers the COM object with the Windows registry.
²dllunregisterserver. It can be sensed that this function and DllRegisterServer are doing the opposite, in fact they are a reverse process that removes all entries DllRegisterServer put in the Windows registry. You can use the Unregister ActiveX server in the IDE to invoke this project.
²dllgetclassobject. DllGetClassObject is responsible for providing COM a class factory, which is used to create a COM object (we also made a clear explanation when discussing the class factory).
²dllcanunloadnow. COM is responsible for calling DllCanUnloadNow to see if the COM server can be unloaded from memory.
Thread Support (Threading Support)
Thread support is only suitable for in-process servers and does not apply to out-of-process servers. In-process servers can be attached to one of several. The threading model for the in-process server is present in the Windows registry, as follows:
² ...
² ...
² ...
² ...
............
Registering the server (registering)
There will be no more mention of registering the server, simply saying why you are registering. As we all know, ordinary DLLs also need to register to run, and COM objects or COM servers to provide services to clients, then the client should first know that there is no this service? How to make this service call or access, so it will find some useful key values, and the customer is looking for the category is the registry. As a result, registration is really necessary and Ken is essential.
Constructors
It should be clear that, as a service object or interface or a component, one step in the work should be done in advance, that is construction, and construction is also initialized, and as we have said before, COM objects are best derived from the Tcomobject class, so that, We have to consider that the constructor defined in Tcomobject calls the virtual method function initialize. If you need to provide initialization code for your COM object, you only need to overload the Initialize method, defined as follows:
Procedure Initialize; Virtual;
The reason for putting the initialization code in initialize rather than in the constructor is that the base class of the COM object in Delphi contains a series of non fictional functions. Root 擗 needs, class factory awards call different constructors in different instances. Initialize is a virtual method and is the only method that can be invoked without regard to which constructor is used to create the COM object.
Create an instance of an in-process COM object
When a user needs to create a COM object in his or her client code, the Createconobject function is typically called, which is defined in Comobj.pas and is declared as follows:
Function createcomobject (const classid:tguid): IunKnown;
Createcomobject the GUID of the COM object that will be created as a parameter and returns the IUnknown pointer to the COM object. Bitterness the requested GUID cannot be found in the Windows registry and an exception is thrown. So let's analyze it together. The implementation of the Createcomobject function is as follows:
function Createcomobject (const CLASSID:TGUID): IUnknown;
Begin
Olecheck (CoCreateInstance (ClassID, nil, clsctx_inproc_server or
Clsctx_local_server, IUnknown, result));
End
We have discussed Olecheck before and now focus on CoCreateInstance. If the root trace CoCreateInstance will find the following information:
function CoCreateInstance; External ole32 name ' CoCreateInstance ';
So it can be argued that the Createcomobject function simply invokes the function CoCreateInstance of Windows and provides some default parameters
CoCreateInstance has five main parameters:
Clsid:clsid is the GUID of the COM server that we want to create. This is the only argument that our specialists pass to Createcomobject.
Unkouter: Use this COM object only if it is part of a collection.
Dwclscontext:dwclscontext determines the type that the reader wants to create. Createcomobject automatically requires the creation of an in-process server (CLSCTX_INPROC_SERVER) or a local out-of-process server (clsctx_local_server). Sometimes another tag used with this function is clsctx_remote_server. This flag is used in DCOM and will be discussed later.
IID:IID is the interface we want to get a reference to it. Delphi usually requires the application of the IUnknown interface, because most classes fail if other references are required. Microsoft uses this parameter primarily for future extensions.
Pv: The main is to get the IUnknown interface pointer.
{One need to register: CoCreateInstance internally creates an instance of the COM object class factory and then uses the class factory to create the object. After the COM object is created, the class factory is destroyed. Obviously, if you want to create multiple instances of the same COM object, this is not very effective, in which case you will be arrogant pathbreaker an instance of a class factory and use its CreateInstance method to create COM objects before deleting it. }
As previously mentioned, Createcomobject usually returns a IUnknown pointer. To get the desired interface pins, use the as operator, such as:
myintf: = Createcomobject (clsid_myserver) as IMyInterface
Instance: a simple COM application
After discussing some of the basic concepts of the COM server, we have a simple little example of how to invoke a COM server that serves as a DLL, and then we extend the COM server and give the advanced programming of a COM server, but everything needs to be done step-by-step.
Example Description:
This instance is when you correctly log on to a COM server. Can implement a simple algorithm, there is no connection between the COM server and the database server, so the login is not a dynamic from the database user Information table to judge, but in the program specified a fixed user name, of course, here, You can connect some text databases to make dynamic judgments. The algorithm here is very simple, that is, the traditional little monkey eat peach problem, a little monkey has some peaches, eat half a day, because greedy, and eat one more, so that every day is more than half one, when the tenth days, after eating only one (here to eat is still eating more than half a), The algorithm is to know how many peaches the little monkey would have.
Problem analysis: Because there are some ways to use a COM server, you can make the following decision temporarily:
The user's information judgment, that is, whether the login successfully let the server to judge for us, the client is simply a simple error checking and data submission, is really a thin client;
{Description: The thin client said here wants readers not to look at the client simply by its literal meaning, not the less the client's code, the better the client's job is to make the server do the thin. In fact, should not be so to understand, and we generally understand that the server/client should be the server to help clients deal with a number of logical, business analysis, and some of the error can be judged by the client to complete, although the client, but it also has its own check in the inside, although the server side, It still has some tasks to be done by the client, and more often, it may be better for the reader to feel that the customer is doing it.
The algorithm is actually very simple, can use the loop, also can use recursion, here just do simple analysis. We use loops to deal with it, we need to start from behind, the day has just eaten a peach, then the tenth day, it should be four, the Nineth day is 10, the eighth day is 22 ... and so on, we can easily draw a total number of peaches, which can be treated as follows:
Var
Acount:integer;
Asum:integer;
Begin
Asum: = 1;
For acount: = ten Downto 1 do
Asum: = (asum + 1) * 2;
End;
It's easy to understand, but after the tenth day, there is a peach left, then the first
