From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17110 invoked by alias); 2 Apr 2003 00:05:54 -0000 Mailing-List: contact guile-gtk-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: guile-gtk-owner@sources.redhat.com Received: (qmail 17103 invoked from network); 2 Apr 2003 00:05:54 -0000 Received: from unknown (HELO mail.tiscali.cz) (213.235.135.71) by sources.redhat.com with SMTP; 2 Apr 2003 00:05:54 -0000 Received: from hobitin.ucw.cz (212.90.239.164) by mail.tiscali.cz (6.0.044) id 3E6FFDAA0041654C for guile-gtk@sources.redhat.com; Wed, 2 Apr 2003 02:03:08 +0200 Received: from 0rfelyus by hobitin.ucw.cz with local (Exim 3.36 #1 (Debian)) id 190TtJ-0000O1-00 for ; Wed, 02 Apr 2003 00:06:01 +0200 To: guile-gtk@sources.redhat.com Subject: Re: guile-gtk: problem in "insert-text" signal handling. From: Daniel Skarda <0rfelyus@ucw.cz> Date: Wed, 02 Apr 2003 00:05:00 -0000 Message-ID: User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/20.7 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-q2/txt/msg00001.txt.bz2 Kevin Ryde writes: > Perhaps the class of the object could be checked too. If it's a > GtkEditable with string+int+pointer parameters then that be tight > enough to avoid hitting anything else. You are right. First I rejected the idea - I was aware of gtk_signal_connect_object function. But fortunately there are no guile-gtk bindings for the function, so the problem looks simple now (though check for GtkEditale+string+... still smells like ugly hack). 0.