Re: [gtkmm] dnd example bug



On Wednesday 29 September 2004 10:25, Borislav Dimitrov wrote:
> Hi there,
>
> I've been monitoring the list for some time because of a problem I have
> with DnD in my app. Here is the post:
> http://marc.theaimsgroup.com/?l=gtkmm&m=108706106627809&w=2
>
> So I recently played (again) with the advanced drag and drop example
> (/usr/local/share/doc/gtkmm-2.4/examples/dnd/ in my installation).
> Everything works ok but if I drag over the trash can happens something
> which look just like an endless recursion or something. The CPU usage goes
> 99 - 100% and I can see my RAM and then swap go away. The whole thing ends
> like this: motion, source (null)
> Terminated
>
> Details:
> gtkmm version: 2.4.5
> glibmm version: 2.4.4
> libsigc++ version: 2.0.5
> gtk+ version: 2.4.9 (from Dropline GNOME - http://dropline.net)
>
> As far as I can remember I've also had the same problem with previous
> releases of gtkmm-2.4
>
> So maybe you want to check it out.
> Anyway I would be extremely thankful if someone helps me with the problem

You have an ActiveThumbnail class publicly inheriting from the Gtk::Eventbox 
class.  You provide an on_drag_data_get() method for it (which overrides the 
virtual method inherited from Gtk::Widget).  From the snippets you have 
given, you also appear to connect the same method to the signal accessed by 
the signal_drag_data_get() method inherited from Gtk::Widget.  This would 
presumably cause the method to be called twice (once by virtual dispatch, and 
once by the signal/slot mechanism), thus explaining your observed effect of 
it being called twice (although in your second report above you now say you 
have an endless recursion).

You do something similar with on_drag_data_received() and 
signal_drag_data_received().

Try omitting the signal connections and only using the virtual function, or 
giving your slot another name and only using the signal.

Incidentally, you seem to be doing something similar with various other 
signals/virtual functions.

Chris.

(Observation: contrary to what seems to be common practice in some of the 
examples I have seen, I avoid giving my slots an "on_..." name for this 
reason.  It is too easy to slip up).



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]