Fw: [PHP-GTK-DEV] GladeXML: signal_autoconnect to an object? (Mystery solved)

From: Date: Tue, 25 Oct 2005 13:43:01 +0000
Subject: Fw: [PHP-GTK-DEV] GladeXML: signal_autoconnect to an object? (Mystery solved)
Groups: php.gtk.dev 
Request: Send a blank email to php-gtk-dev+get-1932@lists.php.net to get a copy of this message
Wrong scope. The Zend engine likes to know where it stands :) If you have gtk::main() in your constructor (which my script had), then the scope is within that class. If you don't (which your script didn't), the scope's general and you need to specify the class. Not a bug. ----- Original Message ----- From: "Steph Fox" <steph@zend.com> To: "Christian Weiske" <cweiske@cweiske.de> Cc: "PHP-GTK dev" <php-gtk-dev@lists.php.net> Sent: Tuesday, October 25, 2005 2:16 PM Subject: Re: [PHP-GTK-DEV] GladeXML: signal_autoconnect to an object? > Christian, > > If MyClass::btnClicked had worked in the first place, I wouldn't have > bothered going to some lengths to make it work last night. > > Your test script is wrong. As I explained earlier, you _cannot_ have $this > as a parameter. Also, GladeXML::new_from_buffer() isn't implemented at > present (and hasn't been). > > Throughout Glade, you have the option to add 'object' or 'after' to any > signal, including signal_autoconnect(). Glade doesn't even _use_ > connect_simple()... > > The whole point of allowing gtk::main_quit as a handler was that you > wouldn't need to call anything more than signal_autoconnect() to use it. > > I have no idea (yet) why your test script fails and my almost exactly > similar test script succeeds. Looking into it, but bear in mind I also have > a job. > > - Steph > > ----- Original Message ----- > From: "Christian Weiske" <cweiske@cweiske.de> > To: "Steph Fox" <steph@zend.com> > Cc: "PHP-GTK dev" <php-gtk-dev@lists.php.net> > Sent: Tuesday, October 25, 2005 7:25 AM > Subject: Re: [PHP-GTK-DEV] GladeXML: signal_autoconnect to an object? > > > > Good morning Steph, > > > > > > > Staying with your example below, you need to declare either > > > "self::btnClicked" or "MyApp::btnClicked" as the callback handler within > the > > > Glade file, rather than plain-vanilla "btnClicked". > > MyClass::btnClicked works, but it's obvious a static call which should > > be ok. > > What not works is self::btnClicked, at least for all five of my signals > > - I always get a > > ------------------- > > cweiske:/data/php-gtk/two/PEAR_Frontend_Gtk2> p5 run.phpw > > PHP Warning: Unable to invoke signal callback 'self::quitDialog' > > specified in /data/php-gtk/two/PEAR_Frontend_Gtk2/Gtk2.php on line 55 in > > /data/php-gtk/two/PEAR_Frontend_Gtk2/run.phpw on line 4 > > ------------------- > > > > But even self:: should have the meaning that the signal is being > > connected to the static function of the current class. So I vote for no > > prefix (no "self::" or so) if that's possible. > > > > I added a test script in the test/ directory. > > > > Btw, could it be that you forgot to commit your new_from_buffer-patch > > which used strlen() instead of some zend zval size things? > > The test script doesn't work for me, and the other new_from_buffer-test > > script not, too. > > > > > > > Adding any parameter to the signal_autoconnect() call simply passes that > > > data to the callback(s), no change there. > > > > > I'd like to make static GTK calls work in a similar way to this - > especially > > > main_quit, for obvious reasons! - but that'll take a little more umming > and > > > ahhing over here... at present there's always an object passed to the > > > callback, exactly as if connect() were being called. > > A signal_autoconnect_simple doesn't really help as _all_ sigs would be > > connected that way. I think that is a pretty hopeless thing; at least if > > you can't split the signal handler functions into groups - those which > > shall be connected simple, and those not. > > > > -- > > Regards/MfG, > > Christian Weiske > > -- > PHP-GTK Development Mailing List (http://gtk.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >

« previous php.gtk.dev (#1932) next »