Useful way of accessing the callback handler

[pvr...@btinternet.com]

In the programming guide, you recommend supplying the object handling the callback as user data to the callback. Obviously this then precludes using user data as a parameter for the callback.

I have a little user method:

    // template function to find the enclosing widget of class WIDGET
    template <class WIDGET>
    WIDGET* ancestor_view(Fl_Widget* w) {
        Fl_Widget* p = w;
        // Keep going up the parent until we found one that casts to WIDGET or we run out of ancestors
        while (p != nullptr && dynamic_cast<WIDGET*>(p) == nullptr) {
            p = p->parent();
        }
        // Return null if we don't find one, else the one we did
        if (p == nullptr) return nullptr;
        else return dynamic_cast<WIDGET*>(p);
    }

As the comment says this goes up the line of parents until a parent of type WIDGET is found.

I then use it like this:

// Windows->Show All|Hide All
// v is bool. false = hide all, true = show all
void menu::cb_mi_windows_all(Fl_Widget* w, void* v) {
    bool show_all = (bool)(long)v;
    menu* that = ancestor_view<menu>(w);
:
:

}

[pvr...@btinternet.com]

Posted too soon, as I hadn't changed the font of the code.

Phil.

[Bill Spitzak]

Using the widget pointer in this was was intended. The callback is allowed to use "which widget" in any way it wants to figure out what to do. It can also do things like look at the label of the widget.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/fb6acb43-e656-4fd7-99a6-45d6285331bdn%40googlegroups.com.