Unsufficient message content

[michelpons]

I am using the GLCC UO in PRO/II 8.3 Patch 1. It relates to a case raised with SimSci-Esscor Support. I have a scenario that calls fro dropping the GLCC UO on the PRO/II flowsheet, to connect inlet and outlet ports, to edit the UO in order to choose the location for its output file, then to calculate the process model made of this UO. Examining the log made with COLTT, I see that get_Values calls on the integer parameters of the UO are at first looking good. Then, after the Edit call, the get_Values calls for integer parameters return a message \"An Invalid Argument\". What is not clear is who is sending this message and then what it means exactly. The only argument of such a call is the returned value. There is no error raised and no means for the call to pass a message. So my educated guess is that COLTT is posting the message but on what grounds. Plus, if it is indeed COLTT which is posting the message, it should be made obvious. Here, as it is posted, one may think that get_Value returns this message. Would it be possible to get more info on what is going on?

[michelpons]

Zipped log file

[michaelhalloran]

This is strange. There is no evidence that PRO/II is calling the error interfaces from the log but it must do because the message reported without logging is the Description from ECapeUser - as shown in the log when COLTT reports the error - nor is it using non-CAPE-OPEN interface like ISupportErrorInfo because COLTT would report that too but it is not shown in the log. I think this one will require a debug session.

I don't understand why the PRO/II error refers to CAS Number when it seems to be CriticalTemperature that is not supported by the package? COLTT shows that CAS Numbers are available for all components.

[michelpons]

I have tested again this ticket using COLTT 2.1 Development Build.

Within the log appears still the following sequence:

Parameter <Check> : Call to get_Value

get_Value returns:
An Invalid argument

Parameter <Check> : Return from get_Vamue - Succeeded
My point is still that i doubt the value is actually \"An Invalid argument\". COLTT is making the analysis that the value returned, instead of being an integer, is something else which is invalid. But it is not obvious to the end-user that indeed COLTT made the analysis especially since the call to get_Value succeeded.
Would be worth looking at what exactly is happening. Installer for the UO will be provided.

[michelpons]

Zipped log file obtained with COLTT 2.1 Development Build

[michaelhalloran]

COLTT now accepts VT_I2 and VT_I4 as valid types for CAPE_INT parameters. CAPE_REAL is also extended to allow VT_R4 and VT_R8.

Fix available in builds after 21 July 2012.