Re: GTK TreeView control in Windows (DND issue)

[John Emmas <johne53 tiscali co uk>]

On 13 Sep 2011, at 11:59, dieterv wrote:

> On Tue, 13 Sep 2011 11:18:50 +0100, John Emmas wrote:
>> 
>> Normally, 'info->context->action' would be whatever action you'd set
>> it to (GDK_ACTION_MOVE / GDK_ACTION_COPY / GDK_ACTION_ASK etc).  But
>> by the time the code reaches that point the action data seems to have
>> gotten lost somewhere.  For a TreeView control (in gtk-win32)
>> 'info->context->action' is always zero.   Consequently, the rest of
>> the process always fails and 'gtk_drag_cancel()' gets called.   This
>> is what's aborting the drop part and it's true, whichever method you
>> use to set up the drag source.
> 
> I think you're on to something here...
> 
>> If nobody already knows what's wrong I'll see if I can look into this
>> and find some more information but it won't be this week.  Probably
>> early next week with a bit of luck.  I'm amazed that this hasn't been
>> solved already though. It's been a problem for a very long time.  I'd
>> be happy to collaborate with one of the devs though, if that would
>> help speed things along.
> 
> Most likely nobody has had the time to look into it. Sadly, there's not
> that many people left working on the win32 port, so all the help we
> can get is *most welcome*!
> 

I found a little more info which might be helpful.  The button release handler in its entirely looks like this:-

static gboolean
gtk_drag_button_release_cb (GtkWidget *widget, 
        GdkEventButton *event, 
        gpointer data)
{
GtkDragSourceInfo *info = (GtkDragSourceInfo *)data;

      if (event->button != info->button)
            return FALSE;

      if ((info->context->action != 0) && (info->context->dest_window != NULL))
      {
            gtk_drag_end (info, event->time);
            gtk_drag_drop (info, event->time);
      }
      else
      {
            gtk_drag_cancel (info, GTK_DRAG_RESULT_NO_TARGET, event->time);
      }

      return TRUE;
}

The 'info' structure has a field called 'widget'.  I wondered if the wrong widget was somehow getting received from Windows (i.e. something other than the TreeView control - maybe the dragged TreeView item or something like that).  But no, 'widget' is set (apparently correctly) to the TreeView control itself.  Next I wondered about 'info->context->action'.  For a working control (i.e. something that isn't a TreeView) this seems to be set to GDK_ACTION_MOVE / GDK_ACTION_COPY or whatever's appropriate.  But for a TreeView it's always set to zero.  However....  zero equates to GDK_ACTION_DEFAULT which is a valid setting AFAICT.  So I don't really understand why it gets excluded by testing for "info->context->action != 0".  Zero isn't an error condition unless I've misunderstood something.

Anyway, there might well be other issues affecting this further down the line - but this is definitely where it all _starts_ to go wrong.  We are at least dealing with the right widget though, so it has to be possible to make it work.  I'll take another look at this sometime during the next week - but if anyone's already looked at it and got some useful info, it'd be really helpful to know.  I'm sure we can crack this if enough people pull together.

John