That would avoid having to inherit from ButtonListener.
Also it would be a step towards keeping everything in one place; it gets a bit cluttered when every UI component requires code in multiple places.
That would still leave resize() code somewhere else. hmm.
I wonder if there's some way to bring that back in as well, so that the only reference to the button object is in myComponent's constructor:
class Foo : Component {
Foo() {
Button* b = new Button();
b->setButtonText("my button");
b->onClick = []{cout << "clicked";};
b->onResize = [this](Button& self) { self.setBounds(...); };
addAndMakeVisible_andTakeOwnership(b);
}
This way b doesn't even need to exist as a member variable.
I suppose JUCE was created well before lambdas even appeared on the horizon.
Jules, have you thought about e.g. stipulating the next version of JUCE will require C++ >= 11, and doing significant reworking of design patterns in light of C++11 features that would break backwards compatibility?
This way b doesn't even need to exist as a member variable.
It needs to be in any kind of scope, otherwise you are leaking...
But the resize stuff is gone, if you use my Layout mechanism. It references via SafePointer and is defined via ValueTree/XML. See http://www.juce.com/forum/topic/layout-class-gui-prototyping#comment-321290
Edit: ok, you just added "addAndMakeVisible_andTakeOwnerShip", which doesn't exist yet, but right, that was my point...
Yes, obviously we've thought of that, and it'll all stuff we want to do!
As we've discussed elsewere, the current plan is to move to C++11 later this year - there are still some unlucky people stuck on older compilers, but at some point we'll have to make the move.
JUCE already has its fair share of macros for various C++11 features, including lamdas if I recall correctly, which are enabled/disabled according to the compiler being used.
