On 17 Sep 2011, at 10:25, John Emmas wrote: > > FWIW I just tried a quick test but the address being printed doesn't seem to > be the main window's address. At the moment, I'm a bit puzzled about what it > might be.... >
I'm no closer to knowing which widget address is getting sent but I think I've made a significant discovery this afternoon. By a total fluke it just so happens that whenever I run my sample app, the TreeView control's hex address (on my system) always happens to end in "F0D0" (e.g. 0x02ECF0D0 would be a typical address). If I mathematically 'fudge' the address received from drag_drop events so that they always end in "F0D0" my TreeView's drag'n'drop functionality suddenly springs to life - i.e. I can successfully re-order my TreeView's rows using drag'n'drop!!! Of course, this isn't a proper solution because it totally screws up DnD for every other type of control but that isn't the point. The point is it shows that if the correct widget address was getting sent on Windows, this would work. So all we need to do is find out why the wrong widget is getting used. I'm wondering if this might be down to a difference between the underlying window managers? For example, when a TreeView drag gets started in X11, maybe the 'X' window manager passes the address of the TreeView control. Whereas Windows perhaps passes a handle for the TreeView item being dragged, rather than the TreeView control itself. It's only a hunch but it sounds plausible to me. Maybe this is something simple like (in Windows) GDK needs to be getting the parent of the window handle it received, rather than just accepting the handle? John _______________________________________________ gtk-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-list
