Re: GTK TreeView control in Windows (DND issue)

[David Nečas <yeti physics muni cz>]

On Thu, Sep 15, 2011 at 01:56:05PM +0100, John Emmas wrote:
> ...
> gtk_drag_find_widget (toplevel, &data);
> 
> and it's that function which invokes the callback.  Inside that function, the relevant code looks like this:-
> 
> if (!data->found && g_object_get_data (G_OBJECT (widget), "gtk-drag-dest"))
> {
>       data->found = data->callback (widget, data->context,
>             data->x - x_offset - allocation_to_window_x,
>             data->y - y_offset - allocation_to_window_y, data->time);
> }
> 
> Initially of course, 'data->found' is zero - so as long as
> 'g_object_get_data()' returns successfully, the callback function
> should get invoked.  Where it all goes wrong is that
> 'g_object_get_data() doesn't return successfully.  It returns NULL.
> Here's the function that's failing:-
> 
> ...
> 
> In gtk-win32, when 'key' == "gtk-drag-dest" (and the drag destination
> is a TreeView) 'g_datalist_id_get_data()' returns NULL.  This is where
> my understanding of GTK comes to a halt.

This datalist stuff is just the underlying mechanism of
g_object_set_data()/g_object_get_data() that allows attaching arbitrary
data to an object, while identifying the data by a string (quark).  It
is often used to attach ad-hoc auxiliary data to widgets and other
objects in applications, occasionaly also within the libraries
themselves.  It might contain some very obscure bug but, generally,
since so many things depend on it I would assume this mechanism works.
Then g_object_get_data() returns NULL simply because nothing has
the data identified as "gtk-drag-dest" is not attached to ‘widget’.

So IMO you need to go one level up and look at what ‘widget’ is and why
it does not have any "gtk-drag-dest" data.  AFAIK the data can be
attached by gtk_drag_dest_set() or gtk_drag_dest_set_proxy() and in case
of a treeview this should happen, quite straightforwardly, if you call
gtk_tree_view_enable_model_drag_dest().

So either "gtk-drag-dest" data fails to be set, gets unset somehow
(cannot see how) or the code above looks for it in the wrong widget.
You check see whether the data is attached to an object any time by
inserting g_object_get_data() calls wherever you suspect things may go
wrong.  Also try printing the widget pointers and compare as they are
the ultimate unique identifiers (as long as the widgets are not
destroyed and the memory reused).

Hope it helps,

Yeti