MouseListener isn't working for me

Heyo, I’ve not used MouseListener before, and I’m not getting the callback. I’ve got a class that inherits from DrawableRectangle, and I want to use the callbacks for clicking and dragging the mouse within this component.

I’ve tried calling addMouseListener(Component*) in the constructor of both my class and the AudioProcessorEditor class (which is my class’ parent component). When calling it in the editor’s constructor, I’ve tried using both “this” and “&MyClass” for the component parameter. I’ve also tried overriding the MouseDown and MouseDrag functions on both the editor and my class. And I’ve tried every potentially valid combination of the above (I think).

Is there something that I’m doing wrong?

Here’s some code to show the structure that would be ideal:

MyAudioProcessorEditor (MyAudioProcessor& p) : AudioProcessorEditor (&p), processor (p)
{
    addMouseListener (&myClass, false);  
    //or...
    //addMouseListener (this, false);
    //... if that would work.  But somebody in a thread seemed
    //to indicate that  &myClass is the proper way
}
//=========================================
void MyAudioProcessorEditor::mouseDown (const MouseEvent& event)
{
    if (event.eventComponent == &myClass)
    {
        //blah blah  code and whatnot
    }
}

However, I could override the MouseDown and MouseDrag functions in MyClass, if need be. But nothing is working. I’ve searched and tried some of the things suggested, and it seems like this structure should be working from what I’ve found. Any thoughts?

Edit: Oh, and I’ve tried myClass.addMouseListener (this) within the editor constructor. Blergh.

OK, I realized that this was keeping it from working:

if (event.eventComponent == &myClass)

Removing that, I’m now getting a callback when I override mouseDrag() and mouseDown() in MyClass, but only when I call the following in MyAudioProcessorEditor’s constructor:

    addMouseListener (&mainWindow.positionBox, true);  //false doesn't work

Also, the mouseDown/mouseDrag functions are being called regardless of where I click. While I only need it within the MyClass subcomponent.

… slowly figuring out MouseListener :stuck_out_tongue:

Mmmmm, got it to do what I want with this sort of thing…

void PositionBox::mouseDown (const MouseEvent& event)
{
    if (event.x > getX() &&
        event.x < getX() + getWidth() &&
        event.y > getY() &&
        event.y < getY() + getHeight())
    {
        encoder->azimuth = ((twoPi / getWidth() * (event.x - getX())) - pi);
        encoder->elevation = ((pi / getHeight() * (event.y - getY())) - halfPi) * -1;
    }
}

Not the prettiest solution, but it’s working. If anybody’s got a a better solution, I’m all ears. <3

1 Like

Hi NoisyNeuron,
I hate to do that, but don’t use Roli’s API-docs anylonger until they fixed the inheriting diagrams.
Look here: http://klangfreund.github.io/jucedoc/doc/classDrawableRectangle.html and open the inheritance diagram and you see, that your DrawableRectangle actually inherits Component and therefore IS already a mouse listener.

When a component gets a mouse event, it will search all it’s children via Component::hitTest(). The one returning true will get the callback.

Here you see the difference of void Component::addMouseListener ( MouseListener * newListener, bool wantsEventsForAllNestedChildComponents).
As you needed to use wantsEventsForAllNestedChildComponents means, that the event was already dispatched to a child of the editor, therefore the editor itself (and it’s listeners) don’t get called.

To summarize: if you call addAndMakeVisible (&myClass), myClass will get the mouseEvents. If you have a complicated form and you want to react only on certain positions or shapes, you can override the hitTest method.

BTW: inheritance diagrams are now fixed.

Right, thanks to the team! Now the important information is visible again.
If now the search comes back and the entries in the diagram are linking again, we shall be very happy :slight_smile:
But one step after another, I am very thankful that you finally got to that issue!

The entries in the diagrams will be links soon, probably within the next week. Unfortunately search is harder to fix and I can’t give an ETA.