On 17 Sep 2011, at 23:21, Peter Clifton wrote: > > Have you tried the GTK patches I pointed you at here? > > www.clifton-electronics.com/tmp/gtk_win32_patches.tar.gz > Sorry Peter. Your patches are on my TODO list but I haven't had time to look at them yet. My gut feeling (though I'd love to be proved wrong) is that this probably (!) isn't connected with grabbing. It seems to be the drag motion events that are getting screwed up (drag_motion, drag_enter, drag_leave etc). When a grabbed item gets dragged around over various windows, each window apparently gets tested to see if it's a drop target. Something's going wrong with that process when a TreeView's involved (possibly the grabbed item is being tested instead of the underlying window? It's worth keeping in mind). However....
On 18 Sep 2011, at 00:03, Dieter Verfaillie wrote: > > I've just completed testing 2.24 with your patches (good > stuff, thanks!) and compared against 2.16 (where this > still worked). > I must admit, I hadn't realised that it was working so recently. I'm using 2.20 (where it's broken) so maybe we should just be looking for what changed between 2.16 and 2.20. Like Dieter, I'm tending to favour a problem in gdk_drag_find_window_for_screen() - or if not there, definitely an issue in either gdkdnd.c or gdkdnd-win32.c. Currently I'm not using version control at my end but if anyone else is, could they take a look at the change log for those files around that time? After all, sudden regressions are exactly the kind of problem that version control is supposed to help with! If there's no-one here who can inspect the change log, maybe I'll move this discussion to gtk-devel. Thanks for everyone's help. John _______________________________________________ gtk-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-list
