Re: Re-setting the callback function from within ... the callback function?

[Chris Quinn <cq htec demon co uk>]

as tends to happen so often, after submitting a bug report I found that gtk_emit_stop_by_name did the trick. gtk_signal_emit_stop had not worked for me so I presumed the former would not either. Unfortunately I was labouring under the impression gtk_signal_connect returned an id suitable for input to gtk_signal_emit_stop, which it is not.

My problem is solved but it seems to have prompted a source level solution. But at what cost? I'd hate to be responsible for slowing down GTK by a few cycles for every signal (multiplied by depth of its propagation) for what amounts to a very esoteric problem that turned out to have a simple (and natural) solution!

Cheers,
Chris

I had formerly tried gtk_emit_stop and ignored by_name, asuming it to be a closely related alternative. Unfortunately I laboured under the impression that gtk_signal_connect returned an identifier suitable for input to gtk_signal_emit_stop. This I subsequently found not to be the case and explains why I never came across the solution sooner.

> > All versions that I know of contain this misfeature. It's possible
> > that Tim who does the signal stuff doesn't agree it's a misfeature, I
> > haven't asked him.
> 
> i think you're right, this is something i've been wondering about since
> around the 1.0 release or so.
> at this point, i don't really expect people to rely on the current
> behaviour, in most cases where you actually encounter it, it's more a
> problem to work around than a feature.
> 
> > You can try to hack on this code, but it's beastly complex in there.
> 
> the actuall change required is not so hard, i've basically added a check
> to the emisson code to not call signal handlers with ids newer than
> the ones given out at the start of the emission (that's just another
> gulong comparision per handler invocation, so not as expensive as e.g.
> "freezing" the list of handlers to call at emission start by doing a
> list-copy).
>