Support

If you have a problem or need to report a bug please email : support@dsprobotics.com

There are 3 sections to this support area:

DOWNLOADS: access to product manuals, support files and drivers

HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects

USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here

NEW REGISTRATIONS - please contact us if you wish to register on the forum

Mouse-over problem...

For general discussion related FlowStone

Mouse-over problem...

Postby Spogg » Wed Apr 17, 2019 9:27 am

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
Attachments
mouse over issue .fsm
(64.16 KiB) Downloaded 714 times
User avatar
Spogg
 
Posts: 3318
Joined: Thu Nov 20, 2014 4:24 pm
Location: Birmingham, England

Re: Mouse-over problem...

Postby tulamide » Wed Apr 17, 2019 10:37 am

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
mousemove.PNG (24.61 KiB) Viewed 10071 times
"There lies the dog buried" (German saying translated literally)
tulamide
 
Posts: 2686
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

Re: Mouse-over problem...

Postby Spogg » Wed Apr 17, 2019 11:31 am

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

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
User avatar
Spogg
 
Posts: 3318
Joined: Thu Nov 20, 2014 4:24 pm
Location: Birmingham, England

Re: Mouse-over problem...

Postby tulamide » Wed Apr 17, 2019 1:02 pm

Spogg wrote: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. :lol:
"There lies the dog buried" (German saying translated literally)
tulamide
 
Posts: 2686
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

Re: Mouse-over problem...

Postby wlangfor@uoguelph.ca » Fri Apr 19, 2019 3:21 pm

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
My youtube channel: DSPplug
My Websites: www.dspplug.com KVRaudio flowstone products
User avatar
wlangfor@uoguelph.ca
 
Posts: 912
Joined: Tue Apr 03, 2018 5:50 pm
Location: North Bay, Ontario, Canada

Re: Mouse-over problem...

Postby trogluddite » Fri Apr 19, 2019 4:54 pm

wlangfor@uoguelph.ca wrote: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!
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
User avatar
trogluddite
 
Posts: 1727
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK

Re: Mouse-over problem...

Postby wlangfor@uoguelph.ca » Fri Apr 19, 2019 8:16 pm

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.
My youtube channel: DSPplug
My Websites: www.dspplug.com KVRaudio flowstone products
User avatar
wlangfor@uoguelph.ca
 
Posts: 912
Joined: Tue Apr 03, 2018 5:50 pm
Location: North Bay, Ontario, Canada


Return to General

Who is online

Users browsing this forum: No registered users and 45 guests

cron