DSP Robotics Support

Probably an issue so easy to solve, that you will laugh about me, but I'm stuck.
I build graphics for the properties view. Now have a look at the images.




The first image shows how the views are tabbed, to be presented based on the index selection. The second shows what's inside the "Add"-module. I can't get this module to properly redraw when the view is changed to it. The props output doesn't carry a trigger. The view input does, but no matter how I try to catch that trigger, it messes up the view arrangement. For example:
If I use the input view trigger to redraw within the "Button Open" module (via event nethod), that button is suddenly drawn over the whole properties area, instead of the module's one.
If I use the trigger as shown above (meaning, with a redraw prim, and it makes no difference if I directly connect to "DoIt", or the way you see here), the redraw works correctly but the mouse area is all over the properties area, instead of just the module's one.
If I forego any attempts to redraw, all is working well. But I need the redraw, because else the previous selected view is still to be seen in parts.

Besides a possible solution that I hope to get from you, I see this as a bug. If I use a trigger, it shouldn't influence the views in any way.

How can I change above wiring (or which Ruby code could be used) to have a proper redraw when that view is selected?

You may feed the trigger from the index selector. That has always worked for me. Preferably put the redraw prim between the multiplexer and "properties" link prim, so the GUI is redraw every time you change the tab.

It's a really weird behaviour you're experiencing there...

KG_is_back wrote:You may feed the trigger from the index selector. That has always worked for me. Preferably put the redraw prim between the multiplexer and "properties" link prim, so the GUI is redraw every time you change the tab.

It's a really weird behaviour you're experiencing there...

Yes!
It was that easy. Placing a redraw prim as you described and feeding the "DoIt" from the index selector works.

(The issue seems to be Ruby, better said, how DSPr implemented view access from Ruby. If you do all this without Ruby graphics, there are no issues redrawing from inside the module.)

Thank you KG

the view connection doesn't send a trigger, i think because the 'flow direction' goes the otherway (so it would be a reverse trigger then)

a view input actually is no input like we know it its more like that the view gets feeded with drawing data, só no triggers to the drawing data

always confusing

Actually the way I see it is this:
View connector carries a reference to the view object. When module GUI is redrawn, what happens is, the MGUI prim fires a view signal (which carries the view object and an an order to draw) rightwards, once a prim receives this view signal, it draws its own stuff and passes the object further right. This is why drawing seems to happen in reverse order - the leftmost components are drawn first, so they end up on the bottom.
When the view connector branches, the branches are calculated in order one by one (once the first is finished, the second one starts etc. ).
Redraws (from redraw prim or ruby) are basically just a view-version of backwards triggers. If you trigger redraw, it searches backwards through the links and finds all MGUI components connected to it, and triggers the drawing on all of them. In a similar way green prims update their inputs, when any of them is triggered.

Difference with ruby is, that views are handled by draw method while all other triggers by event method.

I agree, that's how I see it, too.
And the last sentence is the issue here, although I can't say what exactly is happening behind the scenes. But it is obvious that the trigger is not just interpreted as a trigger, but also sets the view (which it shouldn't!).

Here's a very simplified example (see attached fsm).