Mouse-over problem...

[Spogg]

Guys, while working on my current project I found an issue I can’t understand.
It concerns the Mouse-over prim.
The mouse area for the prim is defined in the module it’s in, and works fine.
But when viewed on the front panel (top level) the mouse position output covers the whole top level and is no longer confined to the area of the “mouse pad” module.

Now, I’ve always found the View system difficult to fully comprehend, so please be patient with me if I’ve made a false assumption. I’d just like to understand why this happens, or even if it’s a bug.

Of course I could make (and have made) a work-around by limiting the float range to the width and height values and holding the value when the mouse exits the mouse pad view area. But surely I shouldn’t have to do this…

See the attached schematic to demo this issue.

Cheers

Spogg

[tulamide]

I must say I am confused.

There are two different prims doing different things. Both work just fine in your example schematic.

Mouse Over is used to paint the frame black or reds, depending on where your mouse is at. You can see that it works on all layers.

Mouse Move reports the position of the mouse relative to the layer it's used. As you can see the values get negative, once the mouse is left of the layer. The only reason you don't see it so clearly on the second layer is that you defined the whole view.
And why is it reporting although you are outside of the mouse area? Because you inherit the top view (via input from MGUI). If you don't want to see values when the mouse is not over the defined area (you guessed it from the italics), use the mouse over output to control the text display. For example like so:

mousemove.PNG (24.61 KiB) Viewed 12970 times

[Spogg]

I must apologise for the confusion I caused by my mixing up Mouse Move and Mouse Over.

My issue was with Mouse Move (the Mouse Over prim was just to change the border colour, as you said).

But you have successfully explained what the Mouse Move does. My assumption was that, since I define a Mouse area with the MArea prim, that the Move prim output would be confined within that area. But you say that the prim responds to the highest level whose view it connects to. I can also see now that the Move prim has no Area input, which is a hint that its area is not directly definable.

I must say that the Component Guide page 296 led me to believe that I was correct in the first place, but clearly you expected the behaviour you described.
I did adopt the solution you came up with already, but I didn’t really see why I should have to do this.

Many thanks tulamide, and again, sorry for the confusion.

Cheers

Spogg

[tulamide]

I must say that the Component Guide page 296 led me to believe that I was correct in the first place, but clearly you expected the behaviour you described.
I did adopt the solution you came up with already, but I didn’t really see why I should have to do this.

And that's the critical part. It is difficult to explain without the programming side behind it. As you can see the only outputs are floats. So it needs to output some kind of number. It can't just change to outputting, say, an empty string. Or just stopping the outputs? Which wouldn't generate triggers, which in some situations could be bad. Also, you'd then see the last values, like a s&h, which also is confusing. And it would break the design of the prims (which is doing one job consistently). Adding another output, maybe a boolean that signals wether the mouse is over the area? I see your brain cells working, and you are right! That is already the job of the mouse over prim.

Some day I'm sure we will work with situational AI PCs, that would instantly understand what we want from them. Until then, however, we have to live with such annoying, but hard to avoid behaviour.

[wlangfor@uoguelph.ca]

It's because of this:
have an extra module not set to graphic in between Your parent module and module with the guts inside.

that way in Your Guts module You'll see:

parent module(Graphic) -> Module -> Guts module (with an MGUI inside)

and then do not put a mgui in the first module, just press (g) to make it graphic. Take a look at My schematics. It's been My workaround. A good one to look at is navigator.

http://dsprobotics.com/support/viewtopic.php?f=2&t=14696

[trogluddite]

It's because of this:...

Incorrect: Spogg's issue would have been just the same regardless of how many levels of module nesting separated the 'parent' view wireless transmitter from the 'child' view wireless receiver.

NB) If you want to include sub-modules which have their own 'child' GUI within a 'parent' module which has an MGUI primitive of its own, connect a wireless transmitter (without label) to the parent MGUI's view output. You just have to watch the order that you make the links, so that the wirelessly received GUI's end up showing on top!

[wlangfor@uoguelph.ca]

Yeah, I just have less issues if I rely on Graphical module versus the MGUI prim. Which is why I said. None of My plugins are broken, but any way You do it is fine. Where I had the most problem was in identifying mouse movements.

I was forced to add a boolean positive to the is mouse events opt.

I've already made about 100+ plugins the same way; I just don't release them all.