Tcl - tkdnd <drop> bindings

Author

tkdnd <drop> bindings

Synic

2006-03-28, 7:04 pm

I have a tkdnd binding:

dnd bindtarget .box text/uri-list <Drop> { tk_messageBox -message "Testing:\n\n%D" }

The .box widget is a Tile Treeview. The platform is Windows XP. It's
ActiveTCL 8.4.12.0 using TkDND 1.0a2.

The problem?

The binding only works every second time the dragged items are held
over the widget. Keep the data held (don't drop), leave the widget,
come back, and the data can't be dropped. Leave again, come back, and it
can again.

First entry: OK.
Second entry: Doesn't recognise the Drop spot.
Third entry: OK.
Fourth entry: Doesn't recognise the Drop spot.

.... And so on. It always follows that sequence.

I'm posting here (rather than emailing the author directly) as per the
recommendation of the package's homepage:
http://iit.demokritos.gr/~petasis/Tcl/tkDND/tkDND.html

Synic

2006-03-29, 10:01 pm

Hi Georgios.

Georgios Petasis wrote:
> You have added a binding only for the <Drop> event? If yes,
> can you please also add a binding for <DragEnter> & <Drag> events?

Is there anything in particular they should be bound to?

Assuming you're after extra troubleshooting info, I tried the following:

dnd bindtarget .box text/uri-list <Drop> { tk_messageBox -message "Testing:\n\n%D" }
dnd bindtarget .box text/uri-list <DragEnter> { tk_messageBox -message "Saw DragEnter" }
dnd bindtarget .box text/uri-list <DragLeave> { set stat "Saw DragLeave" }
dnd bindtarget .box text/uri-list <Drag> { set stat "Saw Drag" }

<DragEnter> is detected every second time as per my original post.

<DragLeave> is caught fine on leaving detected <DragEnter> instances.

Georgios Petasis

2006-03-30, 4:02 am

These bindings should return things, like the action of the drop. Please
look into the demos.

George

"Synic" <flavp+hfrarg@nhgbaf.arg.nh> wrote in message
news:slrne2mhpf.eoq.flavp+hfrarg@sparrow.autons.net.au...
> Hi Georgios.
>
> Georgios Petasis wrote:
>
> Is there anything in particular they should be bound to?
>
> Assuming you're after extra troubleshooting info, I tried the following:
>
> dnd bindtarget .box text/uri-list <Drop> { tk_messageBox -message
> "Testing:\n\n%D" }
> dnd bindtarget .box text/uri-list <DragEnter> { tk_messageBox -message
> "Saw DragEnter" }
> dnd bindtarget .box text/uri-list <DragLeave> { set stat "Saw DragLeave" }
> dnd bindtarget .box text/uri-list <Drag> { set stat "Saw Drag" }
>
> <DragEnter> is detected every second time as per my original post.
>
> <DragLeave> is caught fine on leaving detected <DragEnter> instances.
>

Synic

2006-03-30, 7:04 pm

Hi George

> These bindings should return things, like the action of the drop.
> Please look into the demos.

As I've mentioned earlier, the first drag over the bound widget succeeds
in showing it's a drop target (so that would be what's returned by the
returned value). It's the second, fourth, sixth, eighth, and so on,
which fail.

There's nothing in the demos or documentation which indicates I'm doing
anything different or unusual.

Even clearing the target and rebinding it (essentially forcing a reset)
after each <DragLeave> makes no difference.

update idletasks ; refresh_dropbox .box

proc refresh_dropbox {w} {
dnd cleartarget $w
dnd bindtarget $w text/uri-list <Drop> { do_something %D }
dnd bindtarget $w text/uri-list <DragLeave> { refresh_dropbox %W }
}

In troubleshooting, I also tried binding the droptarget to a ttk::label
and a standard tk label. It made no difference, so Tile's bindings (in
Treeview or elsewhere) aren't to blame.

It shouldn't make much of a difference, but, the drag source is a
selection of files in Windows Explorer.

At this stage, I'm thinking it may be a bug with no TCL based work
around, at least on the Windows XP platform. Perhaps Microsoft changed
some code somewhere?

Synic

2006-03-30, 10:02 pm

Hi George

> Can you try running the demos? Do the demos suffer from the same
> problem?

Same problem observed with your WinDemo.tcl app as with mine.

> I see that you avoid defining the drag enter and drag events. Why?
> Tey are important, as they return the drop action. Perhaps the behaviour
> you observe is due to this!

Buttons 1 and 3 are already bound to actions in the Treeview which is
the drop site.

Sponsored Links