[gtk-list] Re: C++ and Gtk

[Jim Weirich <jweirich one net>]

>>>>> "Brian" == Brian Stempel <stempel@oneimage.com> writes:

    Brian> In fact, I think that using "this" is probably the most
    Brian> flexible choice as a candidate for the slot, [...]

>>>>> "Kenneth" == Kenneth Albanowski <kjahds@kjahds.com> writes:

    Kenneth> Consider two buttons, routed to the same handler, with
    Kenneth> only the "data" value to distinguish them. ("Zoom in"
    Kenneth> vs. "Zoom out", if you like.) More importantly, and to
    Kenneth> prevent separate handlers from being used, consider an
    Kenneth> indeterminate, or at least large, set of objects
    Kenneth> constructed at run time, connected up to the same static
    Kenneth> handlers. Since you've got two variables here (object in
    Kenneth> which method should be invoked, and value indicating
    Kenneth> which object triggered the request), they need to either
    Kenneth> be distinguished with the "data" value, via the widget
    Kenneth> value itself, or (most readily) with set_data/get_data in
    Kenneth> the widget.

I've used the "this-in-the-data-slot" technique in Motif programming
and found it to be quite flexible.  Most of the time, the data you
need to differentiate between the button (ZoomIn vs ZoomOut in your
example) already exists in the object.  On those rare occasions where
you need extra data, you just add it to the object.  Remember,
although we are dispatching to single static handler, the handler
forwards call to virtual member function of the object, so we let the
object handle the work (after all, that's the point of using OO
technology).

    Kenneth> [...] so you need to put together a small struct
    Kenneth> containing both the 'this' pointer, and any additional
    Kenneth> data needed to distinguish the calls.

I've found that putting the data in the object (rather than creating a
struct to hold both "this" and the data) is a satisfactory solution
here. 

    Brian> AFA MenuFactory, [...] I still do not see why a
    Brian> MenuFactory, ensconced in some type of menu managing class,
    Brian> could not achieve the same effect? [...]

    Kenneth> Because we are back to using the "data" pointer for
    Kenneth> 'this', but we might want to store another arbitrary
    Kenneth> value, to trigger the handler in some fashion, or (in a
    Kenneth> patch that hasn't made it in to the dist) to easily
    Kenneth> handle radio items.

Like Brian, I haven't looked at the MenuFactory stuff yet, so I will
reserve judgement here (but its on my list of things to investigate).

-- 
-- Jim Weirich     jweirich@one.net    http://w3.one.net/~jweirich
---------------------------------------------------------------------
-- "A distributed system is one in which I cannot get something done
-- because a machine I've never heard of is down."   --Leslie Lamport