Personal tools
You are here: Home Forum Extension of the platform Problem with SUIT_DataOwnerPtrList

Problem with SUIT_DataOwnerPtrList

Up to Extension of the platform

Problem with SUIT_DataOwnerPtrList

Posted by Timo Siltala at May 14. 2017

Hi again,

in Atomsolv example selection method there is following code:

    const LightApp_DataOwner* owner = dynamic_cast<const LightApp_DataOwner*>( anOwnersList[ i ].get() );
    QStringList es = owner->entry().split( "_" );

looking at the owner->myEntry with debugger, I can't see any underscores "_" in the data but it is used as a splitting character. How does this work?

Best regards,

Timo

Re: Problem with SUIT_DataOwnerPtrList

Posted by Vadim SANDLER at May 15. 2017

See ATOMSOLVGUI_DataObject::entry() method.

Re: Problem with SUIT_DataOwnerPtrList

Posted by Timo Siltala at May 15. 2017

Yes, there it is. Many thanks! So it is added there on purpose. Wide nose hides sometimes few lines of a print...

Then I found another problem: how to get MESH from a entry? There is  a method MeshObjectFromEntry in SMeshStudyTools class but that might be for Python only? I can't find the corresponding header .h file for using it in C++. Is there one at all?

Another route using SMESH::IObjectToInterface was used in another module but the parameters and their purpose remains unclear due to missing explanations. Is that something special an occasional user should not touch at all?

Best regards,

Timo

Re: Problem with SUIT_DataOwnerPtrList

Posted by Vadim SANDLER at May 15. 2017

General approach to access some SALOME object via its 'entry' is to use SALOMEDS API.

In terms of SALOME data model, 'entry' is an address of  the data object in the SALOME study. Data model of such modules like Geometry (GEOM) or Mesh (SMESH) is based in SALOMEDS CORBA services ("light" modules normally do not follow this model and below described way to access data objects is not suitable for them). For GEOM and SMESH modules 'entry' is a internal address of data item in SALOME study data tree. This address can be used to access SALOME study data object which, in its turn, stores a reference to GEOM or SMESH data object, by means of corresponding CORBA interface (implemented in each such module - for example GEOM::GEOM_Object or SMESH::SMESH_Mesh).

In general, you need a reference to SALOME study, in order to be able to access its data. Provided you have a CORBA reference to SALOME study, you can obtain a reference to SMESH mesh object in the following way:

SMESH::SMESH_Mesh_ptr GetMeshObjByEntry(const std::string& entry)
{
  SMESH::SMESH_Mesh_var mesh;

  SALOMEDS::Study_var study = get_ref_to_salome_study(); // here we have reference to SALOMEDS study
  SALOMEDS::SObject_var sobj = study->FindObjectID(entry.c_str());
  if (!CORBA::is_nil(sobj))
  {
    CORBA::Object_var obj = sobj->GetObject();
    if (!CORBA::is_nil(obj))
    {
      mesh = SMESH::SMESH::_narrow(obj);
    }
  }
  return mesh._retn();
}

Mentioned SMESH::IObjectToInterface template function does something like that.

Surely, you'll need to include header files defining corresponding interfaces.

Re: Problem with SUIT_DataOwnerPtrList

Posted by Timo Siltala at May 15. 2017

Thanks again,

To know which header to include I tried to find the function GetMeshObjByEntry from developer docs but neither Kernel, GUI nor SMESH didn't mention it as a data field or function to any classes. Same seems to be the situation with get_ref_to_salome_study(). Even Google can't help. Where should one dig this information? Somehow I assume it has to do with SALOMEDS but no documentation seems to be written from it.

Best regards

Timo

Powered by Ploneboard
Document Actions