On 06/05/2015 12:51 PM, Andreas L. wrote:
, and if they are used in
a field for which the block specified a callback method, that method
will be included in a python function that gets called by blocks that
GRC knows can change variables (e.g. GUI input elements); this mechanism
of calling the callbacks doesn’t really work without special glue;
ok and this glue (swig file) is produced by a process triggered by the
make command in a gr_modtools environment ?
There’s more glue involved than just swig here. Again, all the magic
that happens behind the curtain can be found when you read the generated
You’ll notice that for some graphical input elements, there are
functions defined that these input widgets get instructed to inform as
soon as things change. That works because the GUI toolkits allow for
this kind of callback-emulation.
How can i tell gr_modtools or make to produce a callback function or
howto program a callback function in the C++ code and the
xml tag in the block xml file myself for my own block so a grc python
variable name from flow graph could be inserted in a field of my new
block later when configuring my new block in the flow graph ?
Not at all. You’ll need to analyze the way the XML blocks for example of
the qtgui widgets are written, and what the generated python code looks
like, and then you’ll have to manually copy that.
Really, do it sooner than later; I do like variables as a means of
thinking when constructing my flow graph, they are O.K. for GUI widgets,
but things get ugly the moment you really want to use them from within a
block – as you might have noticed GRC variables originally were
really meant only to be used by python during flow graph creation, and
the whole dynamic reconfigurability of variables at run time came later,
but before message passing worked the way it does now – if I may throw
in wild speculation, I’d assume that if GRC was re-invented today, it
would just set up a message handler for each block using a variable, and
just allow the block author to specify what happens in that message
handler, as well as forcing every variable-changing block to have a
message output port; but: GRC has been around for quite some time, and
its maintenance is a remarkable effort, plus people get slightly
irritated when their block XML stops working.
Is there a particular reason why you wouldn’t use messages?
If you need to use a block that doesn’t take instructions via messages,
write a hier block that accepts messages from the blocks inside of it,
and translates them into getter/setter calls on other blocks; or, better
even, if you think the block you want to use would profit generally from
having a message port for commands/settings, fix that up-stream. There’s
virtually no overhead to having a message port/handler!