Thank you Yeti for you reply. Now I can see that I should've added somecontext to my questions. What I mean by a default handler is a piece of code that gets executed whenan object emits a signal, and which code you don't have to write yourselfbut is there, somewhere already (as opposed to a custom handler that I'dattach to an object with g_signal_connect()). I am currently playing withGStreamer framework, where I create elements that emit signals in responseto particular situations, e.g. disconnection from other elements. Then athing that I call "a default handler" catches those signals and doessomething accordingly. For example, I can create an element of type GstBin:[http://gstreamer.freedesktop.org/data/doc/gstreamer/stable/gstreamer/html/GstBin.html]in which I can place other elements. Every time an elements is placed in abin an "element-added" signal is emitted:[http://gstreamer.freedesktop.org/data/doc/gstreamer/stable/gstreamer/html/GstBin.html#GstBin-element-added].Now what I want to do is to block/freeze/temporarily disable the handlerthat is about to get executed, or hijack the signal. I've just stumbled across g_signal_override_class_handler () method whichseems to be sort of what I'm after... I'll try that tomorrow (-: David Nečas (Yeti)-2 wrote:> > On Fri, Jul 31, 2009 at 06:24:37AM -0700, machinegodzilla wrote:>> >> I created an object that emits different signals depending of what has>> happened. I know the names of those signals. Now I'd like to have some of>> the signals not to be emitted from time to time. To do that I need to>> block/disconnect specific handlers. However, the methods to do that>> require>> handler ids to be passed as arguments.>> >> How do I get ids of default handlers? Or maybe I need to do it some other>> way in this case?> > The class closue (if you mean that by default handler, i.e. the method> passed to g_signal_newv()) is not a handler hence, it has no id and> cannot be blocked by the blocking functions.> > If the class closure is of the run-last kind, you can do many things> such as using the accumulator mechanism (similarly to Gtk+ handling of> events) or stopping the signal emission in your own signal handler.> > If it runs first there's not much you can do to prevent it from running.> > If you do not want the signal emitted at all then simply don't emit it.> I suppose you wrote the class so you can use some flag to tell the> objects to avoid the emission and that not invoking the class closure is> safe.> > If you didn't write the class then preventing the class closure from> running is not a good idea because it can bring the object into an> inconsistent state and Bad Things will happen.> > For property notifications, you can also use the freeze/thaw mechanism,> providing that you are willing to let the handler run later.> > Or you can make the handlers smarter so they avoid the unwelcome action> themselves. > > Hard to tell without knowing *why* you want to prevent the signals from> being emitted...> > Yeti> -- View this message in context: http://www.nabble.com/How-to-get-id-of-remove-a-default-handler--tp24755772p24764068.htmlSent from the Gtk+ - General mailing list archive at Nabble.com. _______________________________________________gtk-list mailing listgtk-list@xxxxxxxxxxxxx://mail.gnome.org/mailman/listinfo/gtk-list
