Re: [gtk-list] obgtk + delete_event again

[Shevek <shevek plaice valhalla net>]

Something like, the delete event is one of two signals added. Now this
didn't use to be the case on 0.99 but it is the case in 1.0. I run olvwm
where when you kill a window it sends a delete event and I had to set up
delete to call back destroy manually. Now it happens automatically. So
when you set a signal on the delete event, there is still at least one
signal int he queue, the deestroy. Now if you remove the window or trash
the pointer to it on the delete event, then when the destroy signal gets
around to it's turn, it's going to dereference a bad pointer and trash the
stack. At least, I think that may be what the problem is. Leave
delete_event alone, unless you need to use it as a
gtk_signal_connect_before on a window or other object, IMHO. Unless anyone
else knows other?

I had this problem for ages.

--
S.
GM/CS/MU -d+ H+>++ s+: !g p2 au0 !a w+++ v-(---) C++++$ UL++++$ UB+
US++ UI+++$ P+>++++ L++++$ 3+ E--- N+ K !W(-----) M+(-) !V -po+ Y+ t+
5++ !j !R G' !tv b+++ D++ B--- e+ u+* h++ f? r-- n---- y?


On Sun, 3 May 1998, fractture wrote:

> I must not be understanding something here because I can't figure why a
> "destroy" event wants the method -delete :(GtkObject *)anObj
> or, why adding a "delete_event" catch to the program results in odd
> behavior.
> 
> Correct me here if I am wrong, but when a "destroy" is connected to the
> object, it in turn sends to obgtk_signal_relay
> the window object,
> the data wich contains the recieving object, and the signal name as the
> method.
> I think the number of args should be 0, and the arg list should be
> empty.
> 
> then
> callfunc turns out to be [signalObject signalName(or destroy in this
> case.)]
> then in the switch it should be calling [signalObject destroy:theWindow]
> 
> right?
> So why does it need -delete to exist in the signalObject?
> 
> Question 2) why does adding "delete_event" the same way ([window
> connectObj: "delete_event" :self]) cause a major malfunction?
> And by major malfuntion I mean,....whe the kill button is hit (the X in
> KDE) A large amount of wierd shit is spit out...like...
> 
> bash$ demo
> error: HelloWorld (instance)
> e  x¬öÿ¿i à àHH?`àöÿ¿Ì Hüöÿ¿÷ÿ¿?÷ÿ¿(Ø ÜX
>                                         @^Ï
>                                           ÷ÿ¿# üöÿ¿üöÿ¿ |@÷ÿ¿ û8÷ÿ¿0@ (
> does not recognize error: HelloWorld (instance)
> %s does not recognize %s
> 
> ^[[?1;2c^[[?1;2c^[[?1;2c^[[?1;2c^[[?1;2c^[[?1;2c^[[?1;2cIOT trap/Abort
> (core dumped)
> bash$ 1;2c1;2c1;2c1;2c1;2c1;2c1;2c
> 
> it also beeps.
> 
> here is the back trace from gdb....
> (gdb) bt
> #0  0x40210f61 in __kill ()
> #1  0x401dd07d in gsignal ()
> #2  0x804bee0 in objc_error ()
> #3  0x804d8b1 in -[Object error:] ()
> #4  0x804d75b in -[Object doesNotRecognize:] ()
> #5  0x804d569 in -[Object forward::] ()
> #6  0x8049dcc in __objc_forward ()
> #7  0x8049c23 in __objc_word_forward ()
> #8  0x4002301c in obgtk_signal_relay (object=0x807cf88, data=0x8082258,
>     nargs=1, args=0xbffff760) at obgtkObject.m:39
> #9  0x4008fa2b in gtk_handlers_run (handlers=0x8082324, info=0xbffff8f0,
> 
>     after=0) at gtksignal.c:1352
> #10 0x4008f423 in gtk_signal_real_emit (object=0x807cf88,
> signal_type=22,
>     args=0xbffff940) at gtksignal.c:1080
> #11 0x4008e179 in gtk_signal_emit (object=0x807cf88, signal_id=22)
>     at gtksignal.c:352
> #12 0x400af528 in gtk_widget_event (widget=0x807cf88, event=0x8085600)
>     at gtkwidget.c:2008
> #13 0x400724a0 in gtk_main_iteration_do (blocking=1) at gtkmain.c:659
> #14 0x400722af in gtk_main_iteration () at gtkmain.c:503
> #15 0x40072109 in gtk_main () at gtkmain.c:409
> #16 0x4001d78c in -[Gtk(App) _run] (self=0x8062ea0, _cmd=0x8053f2c)
> #17 0x8048f57 in main (argc=1, argv=0xbffff9fc) at HelloWorld.m:56
> #18 0x8048b6e in ___crt_dummy__ ()
> (gdb)
> 
> you can view the source here.....
> http://members.xoom.com/jik_/HelloWorld.m
> http://members.xoom.com/jik_/HelloWorld.h
> 
> -- 
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
>