CopyFromMaterial implementation question

[jrdp]

I have a question regarding the correct implementation of the CopyFromMaterial function. In order to get the Dymola Simulator working with CAPE-OPEN fluid property models, we are implementing our own Material object. As per the CO Thermo 1.1 specification, our own Material class inherits from the ICapeThermoMaterial interface (among others) and we are implementing the functions for that interface. As a template for all the functions, we have used the output of the Visual Studio CO class wizard. For the CopyFromMaterial function, we have the following declaration

Code: Select all

  void CopyFromMaterial(/*in*/ CAPEOPEN_1_2::CapeThermoMaterial source);


If we use this input type, and pass our own Material object to this function, I understand that within the function, we only have available the functions of ICapeThermoMaterial to retrieve and copy the properties of the source object - i.e. in this case GetOverallProp, GetSinglePhaseProp and GetTwoPhaseProp.

If the above assumption is correct - which I am not sure of - then how can the CopyFromMaterial function know for example what the basis of the properties stored in the source object are, since these are inputs to the getter functions?

Should the CopyFromMaterial function parameter type be changed to our own Material class in our implementation? Then we would be able to access all the data we need.

[jasper]

A potential implementation to avoid this is to:
- define a custom interface that returns a pointer to the Material Object (e.g. in a low and high integer part)
- implement this interface on the material object
- in CopyFromMaterial, query source for your custom interface
- if it is not there, return an error stating that you cannot copy from a foreign material object
- if obtained, get the pointer via your custom function
- use a C++ cast to cast it to your material object
- talk to the thing directly

A slightly simpler implementation is:
- QI source for ICapeInterface, this pointer is unique
- cast it using C++ machinery to your material object (have a look at the returned pointer from the debugger, you can probably directly figure out how to cast it from there)

Note that the second implementation does not guard against the potential pitfall of the object being casted is not actually your own material object implementation, which will subsequently surely lead to a crash, but under 'normal' conditions this should not happen.