Hello there,
Needing to implement some dropping behaviour in list UI widget from the palette I see that has this as target for dropped node:
./dropUpdater
However this node does not seem to exist. As a result, callbacks such as onDrop() do not seem to be working. I’ve written my own onDrop script to handle drop callbacks but would be nice to be able to use the methods as described in the documentation for list and lister:
See onDrop or onDropHover()
Thank you!
Version 2020 2368, Windows
+1 was looking at this the other night and went digging for missing pieces.
+1 was dealing with this yesterday.
I see something’s broken in there but it’s not obvious what. Feel free to send test files or info to ivan@derivative.ca
Okay I see what you’re talking about. That dropUpdater script looks like it’s ignored. If I add this into my list callbacks DAT, everything seems to work. Definitely post (or send me) examples of problems and what you’re trying to do.
def onDropHover(info):
debug(info)
return True
def onDrop(info):
debug(info)
@Ivan am I doing something wrong here?
dropping onto this lister just creates a node inside the lister
drop-test.toe (7.2 KB)
As a follow-up here. I tested with both the list from basic widgets and the lister from just the general UI bin.
Yeahhh. listCOMPs are weird in that they have their own drag/drop system for cells. This one was set to legacy drag/drop system in the drop par, which is the standard node system. It was intercepting the drag/drop.
You need two things to make this work…
turn ‘drop’ par (On Dropping Into) to Use Parent’s Drop Settings. I know this is weird, and it’s something we’re working on internally as we develop a new drag/drop system. But that is the setting you want.
You need an onDropHover callback. Listers (and raw listCOMPs) need to return True in the hover callback in order to receive the drop callback. So use the callbacks in my comment above to get started.
As I look at this, the gotchas are striking. The legacy drag/drop system leaves a lot to be desired, and we are in the process of developing a much better one.
Woah… okay.
So the last thing that was tripping me up - and may be tripping up @dylanroscover as well - is that you need a row to drop something onto. Said another way, you need an empty that will act as a receiver for your data. @Ivan am I understanding that correctly?
I was imagining that you could do something like drag onto an empty lister and dynamical construct new rows, and couldn’t figure out what I was doing wrong.
I’m sure there’s an approach - just thinking about dragging from one lister to another, and wanting to dynamically create a new list from a source.
@Ivan Thanks for the info; I have it working now.
Would be great if your info from this thread could get passed into the Lister Wiki page, or at the very least, the page could be flagged as “In Development.” Cheers.
@raganmd on the listCOMP there is a parameter called Off Cell Callbacks. If this is on, you shouldn’t need anything to drop onto.
@dylanroscover Imma add this stuff to the wiki right now
Also, watch for ‘fromListerInfo’ in the drag and hover callback dicts. I added some features to help with lister to lister movement.
Foof. Looking at this, I think I was wrong about having to change the drop script. It works for me even if I set to ‘Legacy’ with sys/drop. So that doesn’t seem to be the problem, which makes me think it’s something else that is being tricky.
Keep the test cases coming if you guys unearth any more weirdness, please!
Yeah the more I play with this, the more it seems like some kind of intermittent state error. Sometimes it works for me and sometimes it doesn’t. That gets into C++ problems that may take more research to unravel. Thanks for bringing this to my attention
(Sorry about spamming the thread as I work!)
This is what I (re)discovered today: If you don’t return True from the onDropHover callback, the regular node drag/drop system is invoked. This means that if a drop script is provided, it will be run.
So if you get an onDropHover callback and you don’t return True and you have /sys/drop as your drop script, it’s going to drop the operator into your lister. Rarely what you want when dropping an operator onto a cell!
I’m going to change some default settings to make it harder to fall into this trap.
@Ivan - thanks for spending a little time on this today. Having another set of eyes here today is really helpful.
Wow, long thread to find in the morning! 
@dylanroscover @raganmd Thanks for chiming in!
@Ivan Thanks for having a look at this and for the info. Looking forward for the final fix!
Is everyone here able to make this work on a basic level? I know the settings are finicky, but you should be able to get drops onto your lister as long as:
I think I finally understand how this is working. Attached is a simple example that lets you drag from one lister to another appending data to a table.
drag-drop-from-lister.tox (60.6 KB)
I might write-up a simple post about this - if only for when I forget how this works in 2 weeks 
Ah great! Thanks for the example @raganmd
Glad it’s helpful. 
Sometimes a place to get started makes all the difference.