Modify Scilab/Xcos Block in Scilab 6 Gateway Function

I would like to modify an Xcos block from within a gateway function using the new (non-legacy) Scilab API, for example, replace the block's model property by a new model structure. In other words, do the same as the Scilab command(s):

m = scicos_model()
block.model = m

However, I did not manage to achieve this behavior with the functions from Scilab 6 API: a block created by standard_define() is correctly passed to my gateway function, where this argument is available as scilabVar of type 128. On the other hand, the Scilab help claims that a block is a "scilab tlist of type "Block" with fields : graphics, model, gui and doc".

Attempts

Assume scilabVar block taken from gateway function argument, string constants of type wchar_t[], scilabVar model holding the result of scicos_model():

1. Application of function scilab_setTListField (env, block, "model", model) returns error status (as its equivalents for MList and List do)
2. Knowing that property .model is at index 3, a setfield (3, model, block) called through scilab_call ("setfield", ...) also fails.
   • This is not surprising: when called directly from the Scilab command line, it ends up with setfield: Wrong type for input argument #3: List expected. .
   • However, a getfield (3, block) works, so that at least read access to the block's data fields is possible.
3. An external helper function

   function block = blockSetModel (block, model)
     block.model = model
   endfunction
   

   also called through scilab_call("blockSetModel", ...) actually returns a block with changed model, but the original block passed to this function remains unchanged. Although ugly, this gives at least a way to construct an individual block structure which needs to be returned as a copy.

Summary

• So, is there simply a function missing in the API, which returns the TList (or whatever) behind a type 128 pointer variable?
• Or is there any other approach to this problem I was unable to discover?

Background

The goal behind is to move the block definition task from the usual interfacing "gui" function (e.g. a Scilab script MyBlock.sci) into own C code. For this purpose, the interfacing function is reduced to a wrapper around a C gateway, which, for example, usesscilab_call ("standard_define",...) to create a new block when being called with parameter job=="define". Modification of the contained model and graphics objects through the Scilab API works fine since these are standard list types. However, getting or setting these objects as attributes .model and .graphics of the original block fails as described above.