Re: digging into enums and flags

OK, it was just worth an 'ask'. Thanks. ----- Original Message ----- From: "Andrei Zmievski" <andrei@gravitonic.com> To: "Steph" <steph@zend.com> Cc: "PHP-GTK dev" <php-gtk-dev@lists.php.net> Sent: Sunday, October 02, 2005 6:05 PM Subject: Re: [PHP-GTK-DEV] digging into enums and flags > No, there is no way to hook into the constants mechanism. I'm afraid > that's the way it will have to be. > > -Andrei > > > On Oct 2, 2005, at 6:51 AM, Steph wrote: > > > What's not sane about the message is, it tells you > > GTK_RESPONSE_ACCEPT or > > whatever is undefined (which it is) but not that > > GTK::RESPONSE_ACCEPT would > > be correct, which would be useful information given that the format > > has > > changed since PHP-GTK 1. I think if I hadn't had Christian's demo > > scripts > > available, I'd still be scratching my head over that one! > > > > I think other people migrating from PHP-GTK 1 will have the same > > problem. > > > > Documentation's obviously going to be the number one way to address > > this, > > but what I'm asking is whether there is any simple, generic way to > > recognise > > and intercept something that used to be valid in PHP-GTK 1, e.g. > > GTK_RESPONSE_ACCEPT, and throw out a better explanation somehow > > _before_ it > > reaches PHP's standard response? > > > > ----- Original Message ----- > > From: "Andrei Zmievski" <andrei@gravitonic.com> > > To: "Steph" <steph@zend.com> > > Cc: "PHP-GTK dev" <php-gtk-dev@lists.php.net> > > Sent: Saturday, October 01, 2005 7:01 PM > > Subject: Re: [PHP-GTK-DEV] digging into enums and flags > > > > > > > >> What's not sane about the message shown by PHP? People should use > >> error_reporting(E_ALL) at all times and clean up their scripts. > >> > >> -Andrei > >> > >> > >> On Sep 14, 2005, at 5:02 AM, Steph wrote: > >> > >> > >>> Andrei, > >>> > >>> I think the weird behaviour I reported earlier was probably just > >>> down to me > >>> getting confused - I can't find the particular script that provoked > >>> one > >>> request for a string from the PHP side and another for an int from > >>> the GTK > >>> side, but I do know how it happened now. > >>> > >>> Here's a short test script from my ever-increasing hello.php: > >>> > >>> <?php > >>> > >>> /* tricksy params - and can the final param work at all if > >>> local_files is > >>> set to TRUE by default? */ > >>> $fcdialog = new GtkFileChooserDialog('GtkFileChooserDialog', null, > >>> Gtk::FILE_CHOOSER_ACTION_OPEN, array('first', Gtk::RESPONSE_CANCEL, > >>> 'second', Gtk::RESPONSE_ACCEPT, 'third', Gtk::RESPONSE_OK, > >>> '_fourth', > >>> Gtk::RESPONSE_APPLY), 'tmp://'); > >>> $fcdialog->connect_object('destroy', array('gtk', > >>> 'main_quit')); > >>> $fcdialog->show_all(); > >>> > >>> ?> > >>> > >>> Now in PHP-GTK 2 you need to type stuff like: > >>> > >>> Gtk::FILE_CHOOSER_ACTION_OPEN > >>> > >>> rather than version 1's: > >>> > >>> GTK_FILE_CHOOSER_ACTION_OPEN > >>> > >>> thanks to the g_typing. But if you don't know this in advance and > >>> do it the > >>> old fashioned way, you get something like "Notice: Use of undefined > >>> constant > >>> GTK_RESPONSE_ACCEPT - assumed 'GTK_RESPONSE_ACCEPT' in C:\php5 > >>> \hello.php on > >>> line 4". In some cases that actually works - submitting the string > >>> 'GTK_FILE_CHOOSER_ACTION_OPEN' appears to, presumably because it > >>> evaluates > >>> to 0 - but submitting 'GTK_RESPONSE_ACCEPT' will cause a > >>> PhpGtkConstructException to be thrown. > >>> > >>> Warning: GtkFileChooserDialog::__construct(): each pair in button > >>> list has > >>> to string/number in C:\php5\hello.php on line 4 > >>> > >>> Fatal error: Uncaught exception 'PhpGtkConstructException' with > >>> message > >>> 'could not construct GtkDialog object' in C:\php5\hello.php:4 > >>> Stack trace: > >>> #0 C:\php5\hello.php(4): > >>> GtkFileChooserDialog->__construct('GtkFileChooserD...', NULL, 0, > >>> Array, > >>> 'tmp://') > >>> #1 {main} > >>> thrown in C:\php5\hello.php on line 4 > >>> > >>> You can see how I got confused. OK so this is a documentation > >>> issue at > >>> heart, but is there any way to give a saner E_NOTICE than the one > >>> thrown by > >>> PHP? > >>> > >>> - Steph > >>> NB This means we can eliminate misbehaviour in enums from the 'u' > >>> issue, in > >>> the sense I meant it at least. > >>> > >>> -- > >>> PHP-GTK Development Mailing List (http://gtk.php.net/) > >>> To unsubscribe, visit: > >>> http://www.php.net/unsub.php > >>> > >>> > >> > >> -- > >> PHP-GTK Development Mailing List (http://gtk.php.net/) > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > > > > -- > PHP-GTK Development Mailing List (http://gtk.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >