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()
:
- Application of function
scilab_setTListField (env, block, "model", model)
returns error status (as its equivalents forMList
andList
do) - Knowing that property
.model
is at index 3, asetfield (3, model, block)
called throughscilab_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.
- This is not surprising: when called directly from the Scilab command line, it ends up with
- An external helper function
also called throughfunction block = blockSetModel (block, model) block.model = model endfunction
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 type128
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.
Starting from Scilab/Xcos 6.0.0, the data-structure behind a block is no more an MList (or TList) so you cannot upgrade the model to your own MList. All the data behind are stored using a classical MVC within a C++ coded Block.hxx.
On each try you made, a serialization/deserialization happens to reconstruct the block model field as a Scilab value.
Could you describe what kind of field you want to append/edit regarding the block structure ? Some of the predefined fields might be enough to pass extra information.