Parameter mapping for IDL (IDL code)
ACS generates an Operation's Parameters as part of the operation declaration. ACS generates code similar to this:
interface Interface1
{
// Operation declarations
char Operation1(
in boolean Parameter1);
};
ACS generates an Exception's Parameters as part of the exception declaration. ACS generates code similar to this:
exception Exception1
{
// Parameter declarations
boolean Parameter1
};
The generation of a Parameter in an IDL file is derived from its properties.
Child items:
Not applicable.
Properties:
• If the Data Type property is set, ACS generates the value as the parameter's data type.
If no data type is specified, ACS generates UNDEFINED_TYPE by default. If you want ACS to generate a different default in the absence of a data type for an Attribute or Parameter, change the default value that is specified in the IDL_Sync.ini file.
Tell me more...Reverser Notes: When reverse engineering a parameter's data type:
◦ If the data type is modeled in the Model or is going to be reverse engineered to the Model, the Parameter's Data Type references the appropriate item.
◦ If the data type is not modeled in the Model and is not going to be reverse engineered to the Model, the Parameter's Data Type is set to the name of the data type (as text).
• If the Description property has a value, ACS generates the Description as a comment.
• If the Mechanism property is set to 'in', 'out' or 'inout', ACS generates the parameter declaration as 'in', 'out' or 'inout' accordingly. For Exception owned Parameters, the Mechanism is ignored.
• ACS generates the Name property as the name of the parameter in the code.
| ACS may modify the parameter name that is added to the code to make it valid for IDL. You can specify the exact parameter name to add to the code through the CODE_GENERATION_NAME property of a Parameter.
Tell me more... |
Other properties are ignored.
Tag Definitions:
Not applicable.