Re: digging into enums and flags
| From: | Andrei Zmievski | Date: | Sun, 02 Oct 2005 17:05:36 +0000 |
| Subject: | Re: digging into enums and flags | ||
| References: | 1 2 3 | Groups: | php.gtk.dev |
| Request: | Send a blank email to php-gtk-dev+get-1732@lists.php.net to get a copy of this message | ||
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 flagsWhat'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