At Wed, 28 May 2008 02:20:15 +0200,
Marcus Brinkman wrote:
>
> At Tue, 27 May 2008 23:34:45 +0200,
> Murray Cumming <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, 2008-05-27 at 18:48 +0200, Marcus Brinkmann wrote:
> > > I don't know a way to squeeze a signal handler before its own
> > > handler. See gtkfilechooserdialog.c:
> >
> > connect_notify() can do this,
> > or you can just call connect() with false for the optional extra
> > parameter:
>
> This does not appear to be the case.
D'oh, I must be mightily confused, because after some more munging
around it works as you suggested. This does the trick:
chooser.signal_response().connect (sigc::bind<Gtk::FileChooserDialog*>
(sigc::ptr_fun (&on_response), &chooser),
false);
The problem was indeed that my handler would run after the default handler.
Here is a diagram that illustrates what happens:
Test case fc.c:
1. gtkfilechooserdialog's response_cb
2. on_response
3. gtkdialog's run_response_handler
Test case fc2.cc:
1. gtkfilechooserdialog's response_cb
2. gtkdialog's run_response_handler
3. on_response
With the above change, 2 and 3 are swapped, making the fc2.cc case
identical to the fc.c case.
I guess what hit me is the fact that Glibmm's signal connect is put
into the AFTER slot by default, whereas in glib the default is to use
the BEFORE slot. I'd suggest to mention this in the book, when
signals are introduced, but in the end I didn't understand ordering of
Gtk+ signals to begin with, so I am not sure it would help a newbie
either way.
Thanks a lot,
Marcus
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
