I've written a test case that anybody can compile and run:
http://www.rutski89.com/static/event_test.c
It contains the following line of code in the any_event() function:
printf("IT WORKS!\n");
That currently does not get printed.
If you can get the test case to print that line of text, you will have
solved my problem.
No cheating,
-Patrick
P.S. Copy-pasteable compiler command for ease of use:
gcc -Wall -Wextra -Werror -pedantic-errors -std=c89 -ggdb -O0
`pkg-config --cflags --libs gtk+-2.0` event_test.c
On Fri, Aug 21, 2009 at 12:02 AM, Patrick M.
Rutkowski<rutsk...@gmail.com> wrote:
> OK, so I've determined that there are no handlers returning TRUE
> blocking the default handler.
>
> In fact, there seem to be no event handlers at all! I tested this by
> figuring out how to query for handlers, and then checking against a
> handler I knew was installed:
>
> http://www.rutski89.com/static/squery.txt
>
> So why isn't my default handler any_event_r() executing?
>
> -Patrick
>
>
> On Thu, Aug 20, 2009 at 9:48 PM, Yu Feng<rainwood...@gmail.com> wrote:
>> The default signal handler is not invoked if any of the customized
>> signal handler returns TRUE or something.
>> Check if there are any handlers connected to this signal later on that
>> returns TRUE.
>>
>> Yu
>>
>> -----
>> gboolean user_function (GtkWidget *widget,
>> GdkEvent *event,
>> gpointer user_data)
>> : Run Last
>> The GTK+ main loop will emit three signals for each GDK event delivered to a
>> widget: one generic
>> ::event signal, another, more specific, signal that matches the type of
>> event delivered (e.g. "key-press-event")
>> and finally a generic "event-after" signal.
>>
>> widget :
>>
>> the object which received the signal.
>> event :
>>
>> the GdkEvent which triggered this signal
>> user_data :
>>
>> user data set when the signal handler was connected.
>> Returns :
>>
>> TRUE to stop other handlers from being invoked for the event and to cancel
>> the
>> emission of the second specific ::event signal. FALSE to propagate the event
>> further
>> and to allow the emission of the second signal.
>> The ::event-after signal is emitted regardless of the return value.
>>
>> On Thu, 2009-08-20 at 21:04 -0400, Patrick M. Rutkowski wrote:
>>> Incorrect,
>>>
>>> The ISO C standard defines the & operator on a function name to be
>>> optional when taking asking for a function pointer, I just use it as a
>>> habit of style.
>>>
>>> Here's a demonstration of this effect:
>>> http://www.rutski89.com/static/funcptr.txt
>>>
>>> I still need help with the ->event GTK problem.
>>>
>>> -Patrick
>>>
>>> On Thu, Aug 20, 2009 at 8:50 PM, Brian J. Tarricone<bj...@cornell.edu>
>>> wrote:
>>> > On 08/20/2009 05:36 PM, Patrick M. Rutkowski wrote:
>>> >> I've got the following code: http://www.rutski89.com/static/gtkevent.cpp
>>> >>
>>> >> I do indeed do this:
>>> >>
>>> >> widget_class->event = &any_event_r
>>> >>
>>> >> but then any_event_r() never subsequently get's called, and I'm
>>> >> certain that the "widget_class->event = &any_event_r" line really does
>>> >> execute.
>>> >>
>>> >> Any suggestions?
>>> >
>>> > You're setting ->event to a pointer to a pointer to a function when all
>>> > it wants is a pointer to a function.
>>> >
>>> > -brian
>>> > _______________________________________________
>>> > gtk-app-devel-list mailing list
>>> > gtk-app-devel-list@gnome.org
>>> > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>>> >
>>> _______________________________________________
>>> gtk-app-devel-list mailing list
>>> gtk-app-devel-list@gnome.org
>>> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>>
>>
>
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
