Crash after GTK2.Entry 'activate' signal: 7.8.352/Windows

[Chris Angelico]

I'm building a cross-platform app using GTK2, and have come across
something that makes the whole Pike interpreter crash (with one of
those Windows "send this report to Microsoft" messages). This occurs
with Pike 7.8.352 on Windows, but not on the latest 7.9 on Linux; I
don't have any other Pikes to test this in.

Code:
---
int main()
{
        GTK2.setup_gtk();
        object mainwindow=GTK2.Window(GTK2.WindowToplevel);
        mainwindow->set_title("Kaboom")->signal_connect("destroy",window_destroy);
        mainwindow->signal_connect("delete_event",window_destroy);
        GTK2.Entry ent=GTK2.Entry();
        mainwindow->add(ent)->show_all();
        ent->signal_connect("activate",enterpressed);
        return -1;
}
int window_destroy(object self) {exit(0);}
int enterpressed(object self) {write("activate!\n"); return 1;}
---
Output:
---
activate!

(pike.exe:4128): GLib-GObject-WARNING **: gtype.c:3362: type id `0' is invalid

(pike.exe:4128): GLib-GObject-WARNING **: can't peek value table for
type `<invalid>' which is not currently referenced
---

Clearly my routine does get called. Is there something I need to do in
that routine to prevent this crash?

Chris Angelico

[Lance Dillon-2]

----- Original Message ----

> From: Chris Angelico <[hidden email]>
> To: Pike mailinglist <[hidden email]>
> Sent: Wed, November 23, 2011 6:20:09 AM
> Subject: Crash after GTK2.Entry 'activate' signal: 7.8.352/Windows
>
> I'm building a cross-platform app using GTK2, and have come across
> something  that makes the whole Pike interpreter crash (with one of
> those Windows "send  this report to Microsoft" messages). This occurs
> with Pike 7.8.352 on  Windows, but not on the latest 7.9 on Linux; I
> don't have any other Pikes to  test this in.
>
> Code:
> ---

>
> (pike.exe:4128):  GLib-GObject-WARNING **: gtype.c:3362: type id `0' is  
>invalid
>
> (pike.exe:4128): GLib-GObject-WARNING **: can't peek value table  for
> type `<invalid>' which is not currently  referenced
> ---
>
> Clearly my routine does get called. Is there something  I need to do in
> that routine to prevent this crash?
>
> Chris  Angelico
>
>

Seems to be windows only (well, perhaps), because it works with 7.9.5 and
7.8.473 on linux.

[larcky]

Chris Angelico wrote

Clearly my routine does get called. Is there something I need to do in
that routine to prevent this crash?

Well it's probably not a good idea to call that routine anyway.  The Gtk docs recommend you don't connect to the 'activate' signal at all.  Maybe it's better to stick with set_activates_default() (unless that crashes as well - aaargh, Windows!).
Just out of interest, Chris, what's your app?
Regards, larcky

[Chris Angelico]

On Sat, Nov 26, 2011 at 1:23 AM, larcky <[hidden email]> wrote:
>
> Well it's probably not a good idea to call that routine anyway.  The
> http://developer.gnome.org/gtk/unstable/GtkEntry.html#GtkEntry-activate Gtk
> docs  recommend you don't connect to the 'activate' signal at all.  Maybe
> it's better to stick with
> set_activates_default()  (unless that crashes as well - aaargh, Windows!).

Interesting. I saw that but passed on it, thinking a dummy button was
a bit of overkill... I still think that, but at least this works and
doesn't crash:

int main()
{
        GTK2.setup_gtk();
        object mainwindow=GTK2.Window(GTK2.WindowToplevel);
        mainwindow->set_title("Kaboom")->signal_connect("destroy",window_destroy);
        mainwindow->signal_connect("delete_event",window_destroy);
        GTK2.Entry ent=GTK2.Entry();
        object dummybutton=GTK2.Button();
dummybutton->signal_connect("clicked",enterpressed);
dummybutton->set_size_request(0,0);
        mainwindow->add(GTK2.Vbox(0,0)->add(ent)->add(dummybutton))->show_all();
        //ent->signal_connect("activate",enterpressed);
        //mainwindow->set_default(ent->set_flags(GTK2.CAN_DEFAULT));
        mainwindow->set_default(dummybutton->set_flags(GTK2.CAN_DEFAULT));
        ent->set_activates_default(1);
        return -1;
}
int window_destroy(object self) {exit(0);}
int enterpressed(object self) {write("activate!\n"); return 1;}

I hide the button by sizing it down to 0x0, and the window doesn't
appear any different (I think). Sure seems roundabout though!

> Just out of interest, Chris, what's your app?
> Regards, larcky

Don't laugh... A MUD client.

https://github.com/Rosuav/Gypsum

It's partly an excuse to get to know github, too :)

Pretty skeletal at present, but my idea is to rebuild my RosMud++
client (which is quite popular) with a few differences:
* On-the-fly editable. I have to shut down RosMud to rebuild it.
* Open source. I can't open-source RM as it includes a small amount of
other-than-my code; it's free of charge but not free software. Gypsum
is free software.
* Cross platform. People keep asking me about a Mac version of RosMud.
There'll be Gypsum on any platform that supports Pike (is there an
Android Pike? :) )
* Easy-to-write plugins. Currently, you need to write a Windows DLL to
build a plugin - plus, a crashing plugin brings down the whole
application.

I'm going to have to pay some cost in performance, but I'm hoping that
it won't be too much.

Mainly, I just think it's ubercool to write a client in Pike that
talks to a server written in Pike. :)

ChrisA

[Chris Angelico]

On Sat, Nov 26, 2011 at 1:50 AM, Chris Angelico <[hidden email]> wrote:

> On Sat, Nov 26, 2011 at 1:23 AM, larcky <[hidden email]> wrote:
>>
>> Well it's probably not a good idea to call that routine anyway.  The
>> http://developer.gnome.org/gtk/unstable/GtkEntry.html#GtkEntry-activate Gtk
>> docs  recommend you don't connect to the 'activate' signal at all.  Maybe
>> it's better to stick with
>> set_activates_default()  (unless that crashes as well - aaargh, Windows!).
>
> Interesting. I saw that but passed on it, thinking a dummy button was
> a bit of overkill... I still think that, but at least this works and
> doesn't crash:

And implementing similar code in Gypsum itself seems to work. So, if I
have this right, the steps I need are:

1) Create a button, sized 0x0, with the clicked signal connected
2) Pack the button into the window somewhere
3) Tell the button that it's allowed to be the default (???? why
aren't buttons always?)
4) Tell the window that this button is the default
5) Tell the entry field to activate the default.

All this because the one-step of connecting to the Activated signal
crashes on Windows. Oh Windows, how we love thee.

Side point: For step 4 I use the GTK2.Window()->set_default() method.
Its docs say that "[w]hen setting (rather than unsetting) the default
widget it's generally easier to call GTK2.Widget->grab_focus() on the
widget". Should this be grab_default()? Is true in both the online
docs and in what I built from 7.9.5.

ChrisA

[larcky]

Chris Angelico wrote

Side point: For step 4 I use the GTK2.Window()->set_default() method.
Its docs say that "[w]hen setting (rather than unsetting) the default
widget it's generally easier to call GTK2.Widget->grab_focus() on the
widget". Should this be grab_default()? Is true in both the online
docs and in what I built from 7.9.5.

That typo seems to originate in the C docs.  It should really be patched up (hint :)
Thanks for the link to your project - I've already learned something from it: Pike has enums!
It's also made me want to try some internet stuff - time to download Caudium...

[Chris Angelico]

On Sat, Nov 26, 2011 at 6:43 PM, larcky <[hidden email]> wrote:

>
> Chris Angelico wrote
>>
>> Side point: For step 4 I use the GTK2.Window()->set_default() method.
>> Its docs say that "[w]hen setting (rather than unsetting) the default
>> widget it's generally easier to call GTK2.Widget->grab_focus() on the
>> widget". Should this be grab_default()? Is true in both the online
>> docs and in what I built from 7.9.5.
>>
> That typo seems to originate in the C docs.  It should really be patched up
> (hint :)

Fair enough! I wasn't sure if it was a docs bug or what, but on
looking at the .pre file I can see the parallel between set_focus and
set_default, which makes it clear what happened. Patch attached.

ChrisA