I would like to to create a button class that the user can click on a button and then, without releasing the mouse button, slide across to another button to enable that button too. So for example a grid of drum machine buttons–the user could swipe across a range of the buttons to enable / disable them with a single gesture.
I just had a quick look at the documentation for the MouseListener class and for mouseEnter() it says:
If the mouse button isn’t pressed and the mouse moves into a component, this will be called to let the component react to this.
When the mouse button is pressed and held down while being moved in or out of a component, no mouseEnter or mouseExit callbacks are made - only mouseDrag messages are sent to the component that the mouse was originally clicked on, until the button is released.
Which would possibly rule out using mouseEnter(), unless I modified the mouseListener class which seems quite drastic!
Obviously I could just create a dedicated button array component that handled all the buttons with a single component, but ideally I would like the flexibility of having regular Juce button instances for each button.
Write a bunch of components to represent the buttons but dont have them intercept mouse clicks. Use setInterceptsMouseClicks(false, false); on them. You could use a juce::Button if you like but it’s probably easier just to write your own at this point.
Then have the parent class do the mouse handling and it’s pretty easy
If you need more details shout we’ve done this a few times.
if I were you I’d just not use juce::Button at all for that. Instead just overwrite the mouse methods of a normal juce::Component to do the thing you want to do. the things that look like buttons on the interface could either be an array of juce::Components or some sort of abstract information that is just interpreted to look like buttons in the ‘main’ component’s paint method. if you decide to make child components, use setInterceptMouseClicks() to make sure those components won’t consume the muose events. only if you do that from the main component you can distribute the action of the events across multiple other buttons at the same time. in your mouseDrag method you’d have something along the lines of
Ah yes this a great way to do it, thanks!! The reason I wanted to use the juce button class is so that I would still be able to use the buttons in the normal way, attaching parameters, writing automation etc, rather than just using an array of images or things that look like buttons.
I am thinking of maybe setting up set up the container class so it has a bunch of juce ‘values’ for each of the the buttons, then use referTo() to bind these values to all of my sequencer buttons (which have setInterceptsMouseClicks turned off). Then I can just switch on or off these values using my container’s mouse handler.
But having said that I still think writing of automation is handled by the juce button class when the user actually clicks on the button (triggering touch etc in the DAW), I don’t think referTo() would trigger writing of automation, but I guess this isn’t a massive deal breaker.
juce::ParameterAttachment can be used whenever you wanna make a unique parameter widget that is not based on the default ones like Button and Slider.
you’d have to make sure the component updates its visuals on parameter value changes and make sure to send begin and end gestures when the component changes a parameter value. apart from that, it’s up to you which other parameter information a custom parameter component should show or use in some way
Oh true, yeah then maybe I can just create a totally bespoke component that does everything I want. Although there might still be some advantages to having separate button components.
a popular example of such a control could be a keyboard component, where you wanna slide across the keys. (juce has one already, though.)
or one of those plugins that let you strum strings right on the interface