CAPE-OPEN

Is there a way to create a string as an output parameter, for example in in the parameter collection, so that it can be displayed in other applications that use the UO?
As far as I overlooked the c++ example UO I have not found a way for this issue.

Best,
Christoph

There are two ways to produce strings. One is via a textual report (implement ICapeReport in CAPE-OPEN 1.2, or ICapeUnitReport in CAPE-OPEN 1.0/1.1), the other is indeed via a string output parameter.

Can you elaborate on the context? (CAPE-OPEN version, are you coding the unit operation yourself, ...)?

Yes I am coding the UO by myself. I think we are using CAPE-OPEN 1.1. The base of the implementation is the c++ Mixer-Splitter UO example.
It would be best for me if the string is returned together with all other output parameters. The aim is to integrate the UO to a Pro/II Simulation.

Pro/II does support string parameters.

So a string parameter looks like the RealParameter, except:

- instead of ICapeRealParameterSpec it's get_Specification should return an object (e.g. itself) that implements ICapeOptionParameterSpec
- get_value/put_value take a VT_BSTR typed value. Missing can be either an empty BSTR or a VT_EMPTY
- get_Type should return CAPE_OPTION
- get_Dimensionality can be left unimplemented (e.g. ECapeNoImplHr)
- ICapeOptionParameterSpec::OptionList can optionally return a list of valid values
- ICapeOptionParameterSpec::RestrictedToList should return VARIANT_TRUE in case the list of options is exclusive (no other values allowed)

1,2) A BSTR value is a pointer (a wchar_t*, to be precise), the value of which is either NULL, or something allocated by SysAllocString or similar functions, and needs to be released by SysFreeString. As the string is passed between applications, it is rather important that not both applications free the same string, so you are responsble for freeing and allocating the correct strings. In general, if COM arguments are marked as [in] you should not free the string (hence you should make a copy at put_value), if arguments are marked as [out] you allocate it but the other side releases it (hence again a copy is needed). If you have two internal variables of the BSTR type your class destructor should release the non-zero values. Hence they should probably not point to the same thing. Many applications use BSTR wrappers, similar to smart pointers, to keep track of this.

3) res.vt=VT_BSTR,
res.bstrVal=SysAllocStringLen(someWstr.c_str(),someWstr.size()) , or res.bstrVal=SysAllocString(someWstr.c_str())

note that the above is only correct for non-empty strings. Empty BSTRs should be nullptr/NULL.

4) making an option list generally causes a GUI to provide a drop down box with options, which is ok for input values. Output values typically do not have such a list of options. You can return an empty VARIANT (vt=VT_EMPTY) or a string array (vt=VT_ARRAY|VT_BSTR) - in the latter case you should put a SAFEARRAY in the parray member, the SAFEARRAY should be 1 dimensional, starting at index 0, and have BSTR members. All of this is allocated by your function, and released by the caller.

5) as the parameter cannot be directly created by the outside world, its CLSID does not matter, and you do not need an OBJECT_ENTRY_AUTO at all.

Does the parameter behave properly in e.g. COCO/COFE?