MouseOver bug

[Perfect Human Interface]

Hey, I seem to have come across a bug with the MOver prim. I have a knob with a label that is only drawn when you mouse over it. It's been working fine, but since adding an MGUI prim to the module the knob is placed in, it no longer updates when I mouse over on the top layer unless I click/hold on the knob. And the knob is being drawn on top.

Using 3.0.4; is this a known/fixed issue?

[djbrynte]

can i see the file? also u can easily make This in knobman musch easier and save space. Like showing values. ah ofc depends on what values u wana show.

[djbrynte]

btw do you mean when u raise the volume or some kind of knob that activates when u hold mouse just over it?

[billv]

I think i remember this issue.
The mouse over has to be in top level of
module. By placing the Mgui in there
its no longer in top level.

For the knob draw issue, try changing
link order .Attach knob first, then label.

[Perfect Human Interface]

I think i remember this issue.
The mouse over has to be in top level of
module. By placing the Mgui in there
its no longer in top level.

Hmm ok, so would that be the view that's feeding mouse messages? It's odd because the other mouse stuff works fine.

There's also another, minor, issue/bug I've noted. If you place an MGUI in a module and then connect more than just a wireless connector to the view, you can't right-click items in the module's top-level display (to move things up/down in draw order). It does make sense (although annoying) that you can't change draw order like this because the connection order is overriding it. BUT the problem is that now right-click either does nothing at all, or it opens the module right-click menu, depending on what/where you click. It's simply confusing behavior. What should happen is the same right-click menu opens up with the move up/down options, but with all the options grayed out.

[billv]

Getting tricky to see where your at now.
If you upload example I can check in
a few hours when I get home.

[Walter Sommerfeld]

Hi PHI,

hope u didn't forgot the Enable mouse moves Bool...

btw.: The mouse Over thingy costs CPU power if u use many of them on a big GUI...

Keep on doing!

[Perfect Human Interface]

hope u didn't forgot the Enable mouse moves Bool...

Well that's the thing, it seems. It's enabled in the module for the knob in question. But after adding the MGUI to the above-level module it no longer works. If I enable it on that MGUI, it does indeed work again. But that's a module that occupies a significant chunk of GUI space so I don't want to have to enable it there (I'm assuming, though I don't know, that mouse moves will use more CPU depending on the size of the gui area).

The alternative is like I was thinking after billv's comment; if I wire the view from the knob's MGUI up to the top level (bypassing the other MGUI), that also works, but then the knob is disassociated with the module it's placed within, which kind of defeats the purpose of it's placement and also disrupts modularity if I want to use such modules in other designs.

I just don't see why it should work this way. It works correctly with front panel enabled, but add an MGUI and it "stops" the mouse moves from reaching the destination. All other mouse functions seem to be unaffected. Seems like a proper issue.

[Nubeat7]

its like Walter already said, thats what the "enable mouse move" bool is for, if it is disabled in the parent it cannot work in the child, if you need that feature in some deep down nested layers you need to enable it the whole chain up to the top level, i don't see any bug there, enable or disable, just that.

btw. i always try to avoid nesting mgui's in general (nesting at all) it just adds drawing layers which just costs performance (i think), the only advantage is to group some knobs and move them together, also when you want to reuse the module, you don't need to nest the gui controls...
its also annoying to switch between the gui layers when placing the controls, and you always need to take care that you don't forget the enable mouse move bool

it makes more sense if you have resizable or moveable windows or when scrollbars are used and you need variable positions of a group of gui elements.

[Perfect Human Interface]

its like Walter already said, thats what the "enable mouse move" bool is for, if it is disabled in the parent it cannot work in the child, if you need that feature in some deep down nested layers you need to enable it the whole chain up to the top level, i don't see any bug there, enable or disable, just that.

But why? Might as well enable it for the entire project if you're going to force that. And as I mentioned, the odd thing is that it works fine if you enable front panel without placing an actual MGUI object, so why can't it work with the MGUI?

btw. i always try to avoid nesting mgui's in general (nesting at all) it just adds drawing layers which just costs performance (i think), the only advantage is to group some knobs and move them together, also when you want to reuse the module, you don't need to nest the gui controls...
its also annoying to switch between the gui layers when placing the controls, and you always need to take care that you don't forget the enable mouse move bool

I would hope it doesn't affect performance... I agree it can be bothersome at times, but others it makes things far simpler. If I have 10 different elements in one small chunk of interface, and I want to move all of that together on the top-level GUI, it's far easier to just click and drag it as one object. Also I have two big chunks of my GUI synced, which makes things much easier since I don't have to make every single change twice and make sure they're exactly the same. Also there's purportedly a feature added in the latest release that lets you move individual elements wrapped in another MGUI from the top level.