Hello,
is there a way to drag (I mean mouseEnter, mouseExit, mouseDown, mouseDrag etc.) Component that is background for other components?
I have four components:
For all of them I call addAndMakeVisible in my plugin editor constructor.
All components has exactly the same size and bounds, one of them is background with hitTest set to all bounds, and other three components have hitTest set to small dots. So outside of those dots I want to drag the first component which is background bit it doesn’t work.
Please help.
Of course I was experimenting with setInterceptsMouseClicks() but it doesn’t work for me. But maybe I do something wrong.
Is there a reason then to make all components the same size? Sounds like it would be easier to just make the “small dot” components the size of the dots you’re drawing… this would also help with this kind of mouse event handling
It looks loke I need to solve it that way, but for me it would be much easier to all those components together the same size, nit of course it’s no necessary.
Now I’ve just found out that I need to make all all components the same size.
The reason is:
I want to be able to remote position of my dots by mouse wheel.
So in that case mouse cursor stays in one place but dot moves. So during mouse wheel rotation I need to change hitTest() coordinates to be equal to mouse cursor when started rotating wheel (instead dot coordinates) - to be able to continue remote dot allthough dot is not under the cursor any more.
So if my Component size is the same as dot then after dot move, mouse cursor will be outside of dot Component, and then I’ve found no matter what is in hitTest() it just doesn’t work.
That’s why I need my Components to have all the same sizes (whole plane of dots moving bounds).
Is that clear?
But then I still can’t drag the background.
Basically: you won’t be able to click, drag, etc. the background at all while you have another component that completely covers it
I think to achieve what you’re describing, you can’t handle the mouse wheel events in the “dot” component itself… like you said: if scrolling the wheel moves the dot then hitTest() will start failing as soon as the user starts scrolling
What is the use case for those components exactly? I think the “right” approach depends on the situation…
Oh I want my dots to be coupling with my audio parameters like in example up/down for volume and left/right for panning, but I want plane for those dots to be zoom able, so I also want to be able to navigate on that plane. Of course I can give some sliders outside of plane to navigate. But I just think it would be much simpler if user can drag the plane (which is in that case background)
Okay gotcha! We do some similar zooming in our EQ graphs, but using a dedicated “ruler” component on the side of the graph that the user drags up or down
Basically I would leave the “zoom” and “pan” (dragging) aspects up to the background component only. The user should expect that if they want to move the entire “view” around that they have to interact with the background. This prevents your parameter-coupled dot components from having to handle these events, which should make the code a bit easier to work with.
The only thing is that you can’t zoom or drag if your mouse is directly above one of those parameter-coupled dots, assuming they intercept mouse events
There also is juce::Viewport, but it doesn’t seem to support zooming…
But it seems to be something trivial. There should be something like:
if hitTest() returns false, then try to hitTest() next component under.
I still can imagine there is some method that can turn on such behaviour. But maybe I am stupid.
