Site navigation

ButtonListener question

MacOSX and iOS
#1

Hello,
I’m using juce_1_33, I have a Window class inherit ButtonListener and I override ButtonClicked(). Now this particular window is modal, so when a user clicks “ok” or “cancel” the result is returned and I delete the window. I’m getting a crash when after clicking “ok” or “cancel” I move the mouse. It looks like it’s receiving a mouse event to a non-existant object. Is there something in the destructor I need to be doing? I’m only getting this behavior on the mac, the PC build is fine.

Cheers

#2

Sounds like a classic c++ deleting-something-twice kind of error…

(I’d also expect that the pc is crashing too, but you’ve probably not got exception catching turned on)

#3

The issue was coming up within Button::sendStateMessage. It would try to send buttonStateChanged and crash.

#4

I seemed to be able to resolve the issue by having myButton->removeButtonListener(this) in the destructor. I’m guessing this was a blunder on my part.

#5

Well if you’ve registered something as a listener, and you delete it without unregistering, then yep, that’s definitely a blunder!

#6

You know, if you changed all this listener stuff to something like boost::signals library, it handles everything like that, not to mention it is vastly easier to deal with in that you can still use a system like you do now, or even give it individual function pointers… It is free to include in your source, even change, just as long as you don’t claim any changes you did as part of boost’s work, you don’t misrepresent the original work, you don’t even need to say you use it… It has one of the least restrictive license’s out.

#7

I find the boost signals stuff a bit convoluted, to be honest. They’ve made something that’s very general-purpose, but I’m not a big fan of the way your code looks when you use it.

The only real difference from my listeners is that in boost, boths ends of the connection keep lists of the things they’re connected to, wheras my listeners don’t maintain a list of the things they’re listening to. I could of course add this, but it’s a lot of extra data and code which would almost never be needed, except in cases where you forget to deregister.

Something I’ve been doing for the next release is increasing the number of specific listener classes, replacing the use of things like ChangeListener with ones that are designed for the classes they apply to - e.g. ComboBoxListener, LabelListener, etc.

#8

That sounds good. And yea, boost:signals is a bit convoluted. I have an action/event class built around it to hide all of it, works exceedingly well and is very easy though.

#9