Item is activated upon button-release-event, but not after reordering.
If the list hasn't been reordered, the very last action condition doesn't need be tested and you can add a bit of sophistication and break the action chain before it reaches this nonsense test:

Your code works, but it looses the handling of the $BUTTON value for release-event. I made a simple flag to store $BUTTON on press-event for later usage.

The code is too dirty (and complex) atm to show, but I will come back to it with a fresh brain and clean up. I had some other minor issues, so I had to change the approach a bit. I will come back with more feedback.

In the end we need to complete a simple, yet complete, example how to use and understand your code.

First let's get rid of [[ $TREE ]] test in the function. The reason for that was a possibly empty $TREE, which occurs when the user drags the item just below itself.

And now the beauty part: Avoid all this (double) saving and copying stuff.
In my previous code all these actions fired with every release event, and of course double with a doubleclick. Made me nervous to think what might happen with speed when the list becomes bigger. Not elegant at all.

Below I attach an improved version that triggers only the main action and nothing else when the user clicks an item. It triggers the saving routine when the user moves an item. Find out why it works

I have tried to instead use doubleclick, but it doesn't seem to work in this combination. And the signal "row-activated" doesn't listen...

Well, "row-activated" , the default action, was listening. At least it listened to the Enter or Space key. It didn't pick up a doubleclick because a simple <action> (= "row-activated") , no matter where it is placed in the code, is always processed after the "button-release-event". With activating BTN_SAVE the action chain of the tree widget comes to an end and actions of the Button widget are processed. The process never returns to the tree widget to continue with the still "pending" row-activated event.

Good news: with above code the default action will now work. Personally I would prefer to use the default action so that the user can use either keyboard (Enter or Space) or mouse (doubleclick).

Just for the record and everybody's amusement here is what I *thought* would be a solution to the "move onto item" problem.

It uses the deprecated table widget.
It nicely allows drag&drop only between items, eliminating the need for a work around. As a bonus it keeps the dragged item marked and does not fall into instant amnesia like tree.

Back to the thread topic and to the OP's question "Is it possible to create an input box in which an action starts immediately when the item is dropped into the box?"

My last attempt worked only for focus model "click", allowed drag only from external windows, required a tmp file and ...OK, let's forget it.

Gtkdialog has no "dropped" signal and so the main problem is to distinguish between manual entry and drag&drop. I'm now convinced that the concept to allow manual entry is bad. Not only does it require very complex code, it also is hardly useful.

After the script exits, icons occasionally fly across the screen, from nowhere to nowhere, as though replaying a drag and drop action. The UFOs do not appear to be hostile, but why do they appear
Fatdog 720 frugal, HP AMD streambook

I needed a "drop zone" for a toolbar which combines the advantages of Wognath's and my own approach
- contains a default text in the entry field. No need to keep the field empty and no need for a frame.
- can be used multiple times without the need to close the dialog

A bit tricky but interesting. I learned that the entry widget does not trigger an "enter-notify-event" signal when the mouse enters the widget with a dragged text but that this signal is emitted - somewhat belatedly - when the text is finally dropped. I also learned that the "enter-notify-event" and "leave-notify-event" signals are always emitted twice, only heaven knows why.

The real challenge was to keep the default text always visible without mixing with the dropped text. I almost succeeded. Now the entry field is only cleared during simple mouse movements and only while the cursor hovers over the field. The default text remains visible while dragging text onto the widget and the dropped text never appears in the field. Good enough for me.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum