Parameter Passing and Type Conversion

The following topics contain important information that must be kept in mind when passing objects, arrays and variables between IDL and an external programming environment:

Object Reference Use

It is possible to pass an object reference to another wrapper object as a method parameter, with the following restrictions.

For example, using the diagram in IDL Access, wrapper object A can have a method that takes an object reference. But the only valid object reference that can be specified is to an instance of wrapper object B, since both have their underlying IDL objects living in the same process, X.

If you attempt to pass in an object reference to an IDL object contained in different processes, the method call returns an error. An error is also returned if you attempt to pass in an object reference that does not reference an instance of an Export Bridge wrapper object.

Arrays of Object References

You can also create an array of object references as long as all the objects being referenced are in the same IDL process as the object using the array.

When creating an array of object references for COM, it must be defined as a SAFEARRAY of variants, with each variant containing the IUknown or IDispatch pointer to a COM wrapper object instance.

When creating an array of object references for Java, it must be defined as a JIDLArray containing an array of JIDLObjectI references.

Array Order Conversion

A method parameter or property value can be an array. When working with multidimensional arrays, it is best to know the array ordering. See Multidimensional Array Storage and Access for details.

However, you must take into account the array ordering of the client-side array and the array order expected by IDL. The wrapper objects will convert array ordering when designated to do so in the Export Bridge Assistant. During wrapper object construction, the Export Bridge Assistant lets you designate a method parameter as an array and then indicate if the array needs to be converted (see Converting Array Majority for details). If the array parameter is marked for conversion, the client array is converted during the method call before being sent to the underlying IDL object. If the parameter is also marked with In/Out mutability (meaning that the parameter is not constant and can be set by the caller and pass the value back to the caller), the array is also converted on the way back to the client. For more information on mutability, see Parameter Information.

However, there are certain cases where arrays are automatically converted and the user does not have the option to designate conversion. When calling the GetIdlVariable and SetIdlVariable methods on a wrapper object, or when an IDL function returns an array value, the array is always converted into the order expected by COM. (For Java, the user has the option to designate conversion.)

Type Conversion

IDL is a dynamically typed language that lets variables change type after creation. Java and COM are strongly typed languages, which require a variable to be given a fixed type when it is created. This difference can lead to type-conversion errors during method calls because the IDL object can redefine the data type of a parameter. When a method parameter is marked In/Out, the updated parameter value is returned to the client upon return of the method. During the method return, the wrapper compares the data type of the input value against the data type of the output value.

The wrapper will perform a loose type conversion in which:

Loose type conversion attempts to convert the variables returned by the wrapped IDL object to the types expected by the wrapper object.

A data conversion error is returned when the above rules are not met. For example:

See Supported Data Types for data types supported by COM and Java.

IDL Error State and Successful Method Return

If your client creates an instance of a COM/Java Export Bridge wrapper object, and calls an object method whose code throws an error, the wrapped method will return an error unless the referenced code resets the internal IDL error state.

In this circumstance, it is best if the wrapped code catches its own error, handles it, and resets the IDL error state. You can reset the IDL error state in the error handling catch block by calling the MESSAGE procedure:

MESSAGE, /RESET

This procedure call sets the !ERROR_STATE system variable back to the “success” state.