This is a simple sample Automation server and client. The server implements a Standard Interface, the ISequentialStream interface. Implementing an Automation object using a standard interface is easier than implementing one with a custom interface, yet I think most of the time we will need to use a custom interface I have also provided a sample registration file. The ISequentialStream interface has only two methods: Read and Write, so there is not a lot you can do with it, but it is a good interface for a simple sample. This sample does not do anything useful, but it might be fun to try using the Read and Write methods for a simple chat program, but to be useful DCOM would be needed.
|
The easiest way to save these files as source/text files (using Internet Explorer) is to either:
|
Note that the actual extension of this sample registration file is "txt" instead of "reg". This is to protect your system since if the file did actually have an extension of "reg" and you were to double-click on the link then the file might be automatically registered into your registry.
The registration file must be modified in the following two ways:
The class id generated by the GUIDGEN tool should be provided everywhere that "{<ClsId>}" is in the sample. It occurs once as data for the CLSID key and it occurs in the key for the class. (I did not explain that well but you can look at the sample for now.) The name of your object's exe with the fully-qualified path should be specified for the LocalServer32 key, which occurs twice. The entries with a version number are probably not required, but they are easy enough to do and therefore worth doing. Note that the path must be specified with double backslashes ("\\") wherever a single backslash is needed.
I recommend using two separate projects for the server and the client.
At the beginning of the source file are #defines for INC_OLE2 and _WIN32_DCOM. The _WIN32_DCOM is for CoInitializeEx. If a server for only NT/2000/XP and above is being developed then the following are equivalent; either can be used:
#define _WIN32_WINNT 0x0400 #define _WIN32_DCOM
The server can be compiled either as a Console or a GUI application. Since I use #defines to determine whether the source code to be compiled is for a Console or a GUI application, the source code is a little difficult to understand, but it should not take longer than a minute to figure things out. Obviously once you have chosen whether to use either a Console or a GUI project, you can remove the code that is not relevant.
I am using _ftprintf and _fputts to write diagnostic messages. They are also known as "CRT Output Routines". If this sample is compiled as a GUI application, then a console is used for showing the CRT output; a normal window is not created. You can easily add code to create a window and such, and you could delete or replace the CRT output.The server calls CoInitializeEx to initialize COM and CoUninitialize to uninitialize COM. CoInitializeEx uses COINIT_APARTMENTTHREADED for the concurrency model, which is the safest but provides less performance.
I hope this sample works (it should) and use of it is reasonably understandable. If there are any errors, then I am certainly interested in knowing about them. I am interested in other comments too. You can send me feedback to the address "Feedback" at "SimpleSamples.Info".
See my Visual C++ Programmer Stuff page for more C++ stuff.