Peculiar interface pointer returned by GetConnectedObject

[michelpons]

Scenario is to log (COLTT 64-bit used) ChemSep UO and open the attached fsd in COFE64. No run done, just loading and then exiting. Within the log:
Port <Feed1_stage10> : Call to get_connectedObject

get_connectedObject returns:
Connected Object : 0000000000000000

Port <Feed1_stage10> : Return from get_connectedObject - Succeeded
Port <TopProduct> : Call to get_connectedObject

get_connectedObject returns:
Connected Object : 0000000000000000

Port <TopProduct> : Return from get_connectedObject - Succeeded
Port <BottomProduct> : Call to get_connectedObject

get_connectedObject returns:
Connected Object : 0000000000000000

Port <BottomProduct> : Return from get_connectedObject - Succeeded

Seems strange that pointer to the object is each time "0000000000000000". Does not seem to mean that no object is connected to the Port since a Disconnect on the Port succeeds. Please check if it is not an artefact of 64-bit architecture.

[michelpons]

COFE 64-bit input file

[michelpons]

Log file obtained with COLTT 2.4.0

[jasper]

Hi Michel,

a value of NULL is ok for a port that is not connected:

"If the Port is not connected, either the connected object is returned as UNDEFINED (NULL or Nothing) or an ECapeUnknown error is returned."

Similarly a disconnect on an unconnected port may succeed.

"The caller can safely assume after using Disconnect that the Port is no longer connected to any object whether an ECapeUnknown error is returned or not. The only reason for the method to return an error is in the situation where the Port is not connected before the Disconnect method is called. But it is not mandatory for the method to return an error when this situation happens."

In both cases it is indeed what ChemSepUO does.

Jasper.

[michelpons]

In this case indeed the Port is not connected to an Object. The Ports are getting connected further down.
I feel that the way the result is displayed is not helpful. COLTT could interpret the returned value as UNDEFINED while displaying also the actual value (either NULL or Nothing). And could add that the Port is not connected as a comment.
More to it, the specification about Disconnect is leaving too many options open. One behavior should be allowed. Better be mandatory.

[jasper]

UNDEFINED can mean NULL (CapeInterface), NULL or empty string (CapeString), CapeIntegerMissingValue (CapeInteger), NULL or empty Array (CapeArray*) .... as programmer I would prefer to see the actual value.