JIComServer as the embodiment of the actual COM server. This serves as the start point for interoperating with COM.
You can either use a ProgID (well known name for the COM server like "Excel.Application" or "InternetExplorer.Application") or use the CLSID directly (IID of the interface).
Typically, you would always want to use the
IDispatch interface (Automation).
For users working with COM servers not supporting Automation, they can work directly with the APIs. They would need to know the operation numbers of the APIs they would be calling on the COM server. These can easily be obtained from the IDL or from the Type Library ("Ole View" for viewing type libraries comes with Microsoft Visual Studio Tools).
The part about obtaining the
JIComServer and getting a reference to the COM object is as shown previously, but instead of using
IJIDispatch you would be going ahead like this:
Please make sure that you call
JISession.destroySession(session) after you are done away with the usage of your session. This will close the sockets to the COM server.
For attaching callbacks , please look at the examples MSInternetExplorer and MSSysInfo.
JILocalCoClass is a representation for a Java server class. Currently, you can implement any IDL of an existing COM server using the
JILocalCoClass and pass it's interface pointer instead of the original COM server and it will work fine. Similar mechanism is exploited for call backs.In our case I had to implement
This definition create a Java component with an IID of
45B5FC0C-FAC2-42bd-923E-2B221A89E092... I just made this one up for uniquely classifying this class...you can equate this to a lib identifier of COM IDL. This is required if there are multilple interfaces being implemented in the same Java Class. If you have only one...you can put it's IID here. I just did not do it for showing the user a possiblity.
JILocalCoClass has the option of instantiating the
DWebBrowserEvents.class or it could use another ctor to pass an already instantiated object. In latter scenario, the object would be used as target for the events instead of instantiating a new one from
Now that we have a Java server, we need to define the methods\events it will handle. This is done using the Method descriptors which are themselves described using the Parameter Objects.
This creates a Parameter Object, capable of defining a IN or OUT type for a Method. Like,
This declares a method descriptor. The first parameter in the ctor is the API name of the api to implement, the second one is it's OP number.This one can be obtained from the IDL\TypeLib. And the third param is the parameter object describing the input\output types of this method. If you do not want to use this ctor, there is another, which sequentially increments the method numbers starting from 1. The calls below add a new interface IID to this Java server. It simply means that the server supports this interface definition.
This will be the list of all COM interfaces which this Java class supports or implements.
The next call attaches the event handler (our JILocalCoClass) to the actual COM server for recieving events for the interface identified by the IID. There can be many such calls on the same COM server for different IIDs.
Now whether you use
IJIDispatch or not, events will work regardless of that. The COM object you have to use in the
attachEventHandler is the COM Object on
which you did the
queryInterface for the
Commented examples are located in the "examples" folder of the distribution.