3 messages in org.gnome.gtk-perl-listRe: GtkEntry - did not receive focus-...
FromSent OnAttachments
Daniel KasakSep 21, 2005 7:30 pm 
muppetSep 21, 2005 10:34 pm 
Daniel KasakSep 21, 2005 10:55 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: GtkEntry - did not receive focus-out-event.Actions...
From:muppet (sco@asofyet.org)
Date:Sep 21, 2005 10:34:33 pm
List:org.gnome.gtk-perl-list

On Sep 21, 2005, at 10:30 PM, Daniel Kasak wrote:

I've hit somewhat of a brick wall with the error:

Gtk-WARNING **: GtkEntry - did not receive focus-out-event. If you connect a handler to this signal, it must return FALSE so the entry gets the event as well at /usr/lib/perl5/ site_perl/5.8.5/Gtk2/Ex/Dialogs/Message.pm line 236. Gtk-ERROR **: file gtkentry.c: line 4857 (blink_cb): assertion failed: (GTK_WIDGET_HAS_FOCUS (entry)) at /usr/lib/perl5/site_perl/ 5.8.5/Gtk2/Ex/Dialogs/Message.pm line 236. Aborted

which results in my app completely bailing out.

Incidentally, the reason for this is that if you inhibit the focus- out handler, GtkEntry has no way to disable the cursor blinking timeout, and the timeout subsequently runs and can cause a core dump because one of his pointers is invalid. That's why they flagged this as a fatal error assertion.

What's happening is that I've connected some code to run on the focus-out event of an entry:

sub on_Prospects_Search_LeadNo_focus_out_event { my $leadno = $prospects->get_widget("Search_LeadNo")->get_text; $prospect_data->query("where LeadNo=$leadno"); return FALSE; }

That return FALSE bit I added just now - it didn't help any.

.... because you weren't getting that far before it blew up. It will help in the future. Read on.

I'm getting into the line:

$prospect_data->query("where LeadNo=$leadno");

From here, my Gtk2::Ex::DBI module is throwing an error ( because I've mucked up the SQL ... but that's my problem ) via Gtk2::Ex::Dialogs. The bit of code that does this is:

eval { $sth->execute || die $self->{dbh}->errstr; };

if ($@) { Gtk2::Ex::Dialogs::ErrorMsg->new_and_run( title => "Error in Query!", text => "DB Server says:\n$@" ); return FALSE; }

I get the error message, but as soon as it appears, the whole app crashes with the above error. What's going on? Where do I have to return FALSE to stop this from happening?

This is a lot easier to understand with a timeline:

- focus into GtkEntry - GtkEntry installs timeout for cursor blinking - focus out of entry - GtkEntry emits focus-out-event - your handler runs **before the default handler**. - your handler traps exception and creates dialog box - dialog box runs nested event loop - event processing continues, focus goes to another widget - entry's cursor blink timeout is still installed, and runs again. entry does not have focus, but timeout has run, so the widget is in an invalid state and calls g_error() with a nastygram. - default handler runs, uninstalls cursor blink timeout

The problem is that you're allowing the event loop to run in your handler for focus-out.

The solution is to get the entry's default handler to run before you do anything that can run a main loop. There are two easy solutions:

a) use signal_connect_after to have your handler run *after* the default handler for focus-out-event instead of before.

b) leave the signal connected normally, but in your "catch" block, instead of running the dialog right then, defer it with an idle, like this:

if ($@) { # oh, crap. pop up the error message when the main loop is idle. Glib::Idle->add (sub { Gtk2::Ex::Dialogs::ErrorMsg->new_and_run( title => "Error in Query!", text => "DB Server says:\n$@" ); FALSE; # don't run again }); # return control immediately. return FALSE; }

and, of course, option c) is "do both."

Hope that works.