Re: FileChooserDialog and response signal

[Marcus Brinkmann <marcus brinkmann ruhr-uni-bochum de>]

At Wed, 28 May 2008 02:20:15 +0200,
Marcus Brinkman wrote:
> 
> At Tue, 27 May 2008 23:34:45 +0200,
> Murray Cumming <murrayc murrayc com> 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