The Bridge Services
Service: com.sun.star.bridge.oleautomation.BridgeSupplier
 |
Prior to OpenOffice.org 2.x the service was named com.sun.star.bridge.OleBridgeSupplier2. |
The component implements the com.sun.star.bridge.XBridgeSupplier2 interface and converts Automation values to UNO values. The mapping of types occurs according to the mappings defined in Type Mappings.
|
Usually you do not use this service unless you must convert a type manually. |
A programmer uses the com.sun.star.ServiceManager ActiveX component to access the office. The COM class factory for com.sun.star.ServiceManager uses BridgeSupplier internally to convert the UNO service manager into an Automation object. Another use case for the BridgeSupplier might be to use the SDK without an office installation. For example, if there is a UNO component from COM, write code which converts the UNO component without the need of an office. That code could be placed into an ActiveX object that offers a function, such as getUNOComponent().
The interface is declared as follows:
module com { module sun { module star { module bridge {
interface XBridgeSupplier2: com::sun::star::uno::XInterface
{
any createBridge( [in] any aModelDepObject,
[in] sequence< byte > aProcessId,
[in] short nSourceModelType,
[in] short nDestModelType )
raises( com::sun::star::lang::IllegalArgumentException );
}; }; }; };
The value that is to be converted and the converted value itself are contained in anys. The any is similar to the VARIANT type in that it can contain all possible types of its type system, but that type system only comprises UNO types and not Automation types. However, it is necessary that the function is able to receive as well as to return Automation values. In C++, void pointers could have been used, but pointers are not used with UNO IDL. Therefore, the any can contain a pointer to a VARIANT and that the type should be an unsigned long.
To provide the any, write this C++ code:
Any automObject;
// pVariant is a VARIANT* and contains the value that is going to be converted
automObject.setValue((void*) &pVariant, cppu::UnoType< sal_uInt32 >::get());
Whether the argument aModelDepObject or the return value carries a VARIANT depends on the mode in which the function is used. The mode is determined by supplying constant values as the nSourceModelType and nDestModelType arguments. Those constant are defined as follows:
module com { module sun { module star { module bridge {
constants ModelDependent
{
const short UNO = 1;
const short OLE = 2;
const short JAVA = 3;
const short CORBA = 4;
};
}; }; }; };
The table shows the two possible modes:
| nSourceModelType | nDestModelType | aModelDepObject | Return Value |
|---|---|---|---|
| UNO | OLE | contains UNO value | contains VARIANT* |
| OLE | UNO | contains VARIANT* | contains UNO value |
When the function returns a VARIANT*, that is, a UNO value is converted to an Automation value, then the caller has to free the memory of the VARIANT:
sal_uInt8 arId[16];
rtl_getGlobalProcessId( arId );
Sequence<sal_Int8> procId((sal_Int8*)arId, 16);
Any anyDisp= xSupplier->createBridge( anySource, procId, UNO, OLE);
IDispatch* pDisp;
if( anyDisp.getValueTypeClass() == TypeClass_UNSIGNED_LONG)
{
VARIANT* pvar= *(VARIANT**)anyDisp.getValue();
if( pvar->vt == VT_DISPATCH)
{
pDisp= pvar->pdispVal;
pDisp->AddRef();
}
VariantClear( pvar);
CoTaskMemFree( pvar);
}
The function also takes a process ID as an argument. The implementation compares the ID with the ID of the process the component is running in. Only if the IDs are identical a conversion is performed. Consider the following scenario:
- There are two processes. One process, the server process, runs the
BridgeSupplierservice. The second, the client process, has obtained theXBridgeSupplier2interface by means of the UNO remote bridge. In the client process an Automation object is to be converted and the functionXBridgeSupplier2::createBridgeis called. The interface is actually a UNO interface proxy and the remote bridge will ensure that the arguments are marshaled, sent to the server process and that the original interface is being called. The argumentaModelDepObjectcontains anIDispatch*and must be marshaled as COM interface, but the remote bridge only sees an any that contains an unsigned long and marshals it accordingly. When it arrives in the server process, theIDispatch*has become invalid and calls on it might crash the application.
Service: com.sun.star.bridge.OleBridgeSupplierVar1
This service has been deprecated as of OpenOffice.org 2.0.
Service: com.sun.star.bridge.oleautomation.ApplicationRegistration
|
Prior to OpenOffice.org 2.x this service was named com.sun.star.bridge.OleApplicationRegistration. |
This service registers a COM class factory when the service is being instantiated and deregisters it when the service is being destroyed. The class factory creates a service manager as an Automation object. All UNO objects created by the service manager are then automatically converted into Automation objects.
Service: com.sun.star.bridge.oleautomation.Factory
|
Prior to OpenOffice.org 2.x this service was named com.sun.star.bridge.OleObjectFactory. |
This service creates ActiveX components and makes them available as UNO objects which implement XInvocation. For the purpose of component instantiation, the OleClient implements the com.sun.star.lang.XMultiServiceFactory interface. The COM component is specified by its programmatic identifier (ProgId).
Although any ActiveX component with a ProgId can be created, a component can only be used if it supports IDispatch and provides type information through IDispatch::GetTypeInfo.
| Content on this page is licensed under the Public Documentation License (PDL). |
