Re: The "widget" problem
Tom <tflynn@gc.cuny.edu> writes:
situation that might arise in a GUI framework where classes are used to
represents widgets like buttons and text boxes.
I've seen /objects/ of classes of for widgets, not classes.
Also we want the process of setting up callbacks to be as
simple as e.g. passing function pointers.
When member functions pointers are used, it is not abvious
how to implement helpful patterns like adapter classes
(?MouseAdapter?) in Java.
Part of the issue is that one cannot make use of a pointer to a member
function without an instance of the class itself.
Do you think of OOP in terms of classes? Then, it would have
to be called ?class-oriented programming?.
Let me know what you think of this solution. Here "button"
and "mywidget" are two widgets in the system, mywidget contains a
button and the wants to receive the press events of the button.
I have not read all of your code. Let me just look at its
interface:
mywidget m; m.b->press();
Something is wrong, when an external entity needs to know
hard-coded that mywidget contains a field ?b?.
I would have thought of it this way: The framework object
has a function:
register_press_listener( ... )
The initialization of the button or widget contains code like
framework->register_press_listener( button );
button is an instance of an abstract class ?press_listener?
with a function
press( ... )
Now, when appropriate, the framework calls this press
function to let the button know about the press event.
(Instead of runtime-polymorphism, the framework function also
could be a template function or member of a template class,
to implement such a scheme using compile-time polymorphism.)