Returning a string in c++ UO as UO Parameter

[SLiebschner]

I never used COCO/COFE.

[jasper]

As an alternative, can you perhaps log the interaction between your unit operation and ProII, using e.g. the CAPE-OPEN logger and tester tool (COLTT)?

https://colan.repositoryhosting.com/trac/colan_coltt

[SLiebschner]

I have no permissions to install COLTT or COCO. Can you think of yet another way to narrow it down?

PS: I made value and defValue a std::wstring instead of BSTR, but it does not help.

[jasper]

I am not sure what you want me to suggest - the snippet you sent me is not sufficient for me to go on - it is still mixing double parameter details (minVal,maxVal,dimensionality (also passed to constructor)) with string parameter details. get_OptionList remains unimplemented, get_RestrictedToList returns NO_ERROR, but returns whatever value was already in the BOOL that was used as input argument, so the outcome is undefined. The constructor takes a pointer value (defVal) by reference.

The construction code snippet you post does not match the argument count of the constructor code snippet you post, so cannot possibly compile (as you posted it).

You cannot install tools to check whether your implementation is functioning, so you leave me really little choice but to read the code line by line, and the code is at best messy, but as said, as you posted it, it cannot even compile. Maybe you can put a bit more effort into cleanup of the code and posting the correct code? Otherwise I feel like I am putting in more effort than you.

I understand that COM programming is unpleasant. CO-LaN also understands this, and a new middle-ware which takes a lot of the COM programming out of the picture, and therefore making things a lot easier, is in the making.

https://www.colan.org/experiences-proje ... ure-cobia/

Code produced with COBIA, or the class wizard (https://www.amsterchem.com/cobiawizard.html) is generally a lot easier to understand and certainly a lot 'cleaner'. Perhaps this is a way forward. If you are however bound to using the COM CAPE-OPEN binding, please clean up the code, post construction code that matches constructor code; only then can I actualy perhaps say something about it (which still would require a lot of work on my end, integrating your code into a test project, and essentially running the logger or interop with a PME myself).

[SLiebschner]

The last code snippets I sent are from 24th March and I want to refer to them in the following.

1. I need to leave the member function get_Dimensionality(...) as otherwise the class becames abstract. Thus I also left the member dimensionality (and also minVal and maxVal) as I don't see how they could harm. Or could they really cause problems?
2. About the get_OptionList(...). I tried to follow your hint from 24th March point 4). What do I miss here? (The parameter in question is an OUTPUT parameter, so a dropdown list is not required.)
3. I changed get_RestrictedToList(...) to

Code: Select all

	STDMETHOD(get_RestrictedToList)(VARIANT_BOOL * vb)
	{
		vb = 0;
		return NOERROR;

Is that better?
4. From my point of view, the parameters in the construction code match the arguments of member function CreateParameter. Where do you see a mismatch?

Thanks a lot for your patience so far! Apart from deleting many comments I don't see how I can clean up the code. (I am only familiar with C++, but not at all with CAPE-OPEN or COM). I guess deleting only the comments is not what you mean.

[jasper]

1) get_Dimensionality can return an empty VARIANT for non-real valued parameters. This is mistakenly a part of the common parameter interface, the CAPE-OPEN 1.2 definition of parameters fixes this.

2,3) in this case, return get_OptionList as an empty VARIANT, and return VARIANT_FALSE (better than 0, although equivelent) for get_RestrictedToList.

4) I misread - apologies. It demonstrates that all I can do is go over the code by reading it.

It would be good to log the interaction between the PME and the PME (ProII) so you can see whether anything goes wrong in the interaction.

[SLiebschner]

Good news first: I got COLTT installed.
But I don't see anything in the log file, which gives me a clue why all output parameters work except the string parameter.

I tried to attach the log file, but it says: "The extension log is not allowed". Similar errors arise if I use txt as suffix or remove it all together. Posting the log inline is certainly too long.
Do you know how I can attach the file? For the time being I uploaded it here: https://mettwolke.dukun.de/s/Gs2bkFosGEKyKpx

[jasper]

the relevant bit in the log is here:

Parameter <version> : Call to ICapeIdentification.get_ComponentName
get_ComponentName returns:
version
Parameter <version> : Return from ICapeIdentification.get_ComponentName - Succeeded
Parameter <version> : Call to get_Mode
Parameter Mode: CAPE_OUTPUT
Parameter <version> : Return from get_Mode - Succeeded
Parameter <version> : Call to get_Type
get_Type returns: CAPE_OPTION
Parameter <version> : Return from get_Type - Succeeded
Parameter <version> : Call to get_OptionList
Warning - optionNames argument is empty

It seems to not ask anything anymore after that. It appears it does not like option parameter that do not have a pre-defined list of options. Perhaps this functionality is not supported by ProII - it does not look like the unit is doing anything wrong at this point. To be continued shortly.

[jasper]

One work around would be to make it a restricted option parameter, with only one option, which is the value you need it to have. The disadvantage of that option however, is that the list of options can only change during Edit. This implies you cannot change the value as a result of Calculate. This would be good enough for a version parameter I suppose - but I am not sure whether this covers any other use cases you may have.

[SLiebschner]

The use case is that the UO calls a Python package, which performs the actual calculation. One output parameter of this calculation is the version number.

It would not be convenient to restrict the parameter (to a list of possible values), as I do not know which versions are yet to came: "1.2.0", "1.2.1", ... "1.3.0", ...