Changing the dragdata for a window reference control

[phantomwhale]

There is some code in my ruleset that need to do different things for the same "type" of data, depending on where it comes from. So, for instance, an NPC dragged from the GM's personality list is treated different to an NPC dragged from a PC's ally list. Both point to an "NPC" object, and both come from lists of windows that have a window reference control to open an NPC window for that data, but I would like to handle them differently where they are dropped. In this case, the combat tracker would like to copy over a lot of data (GM NPC) or link to a bunch of data (PC Ally). In the former case, the data is acting like a template, copying over values for a new instance of that NPC, in the latter the data being dragged is for the very same instance of the NPC - a copy of the ally is NOT made.

Hope that's clear ! Anyways... my thoughts on this were that it would be handled via different dragdata types. Have the combat tracker list of NPCs handle an "ally" type different to how it currently handles the general "npc" type. Right now, it needs to look at the name of the database node that the NPC came from, and deduces anything that originated from the "charsheet.###" nodes must be an ally, but I'd rather not build that level of DB knowledge into the windows.

But my attempts to change the dragdata of a window reference control have so far failed - they always seem to still just be a "shortcut" type dragdata node when they get dropped, and when I look at the dragdata object in an onDragStart() method, the dragdata object has type "none", as if I am being given a dummy object, which no matter what I call on it gets thrown away, and a shortcut dragdata object still being created.

Can someone confirm if this is the case ? And if window reference control's drag behaviour is locked down ? Equally interested to see if this approach is a wise one or not, perhaps there is a better way of doing this that I haven't thought of ? I'd rather not make my own genericcontrol to do the drag and drop, and I'd like the control to still have all the behaviour of a window reference control (e.g. click on it to open a window of the appropriate class and database node)

Regards,
Ben (-PW-)

[Moon Wizard]

Are you making sure that you "return true" from the onDragStart event? Otherwise, anything that you set on the dragdata object will be overwritten by the default behavior.

When I implemented the more advanced item drag and drop (i.e. transfer), I actually used the first approach. I look at the database node name to determine whether an item originates for the drag event and where an item is targeted on the drop event. The code acts differently based on whether it is a character sheet, the party sheet (i.e. party treasure), a treasure parcel (i.e. group of items) or the campaign item list.

Regards,
JPG

[phantomwhale]

Are you making sure that you "return true" from the onDragStart event? Otherwise, anything that you set on the dragdata object will be overwritten by the default behavior.

*Facepalm* thanks !



When I implemented the more advanced item drag and drop (i.e. transfer), I actually used the first approach. I look at the database node name to determine whether an item originates for the drag event and where an item is targeted on the drop event. The code acts differently based on whether it is a character sheet, the party sheet (i.e. party treasure), a treasure parcel (i.e. group of items) or the campaign item list.


I guess in this case, I have a "list of PC allies" and a "list of GM controlled NPCs". Contextually, I know they are often handled differently for drop targets, so can go with custom types to provide this information.

With a list of items, I guess all I know is they are items. They could be dragged onto various targets, each of which might have a different effect (e.g. move inventory, drop inventory, pass item to another player). So I guess I'll need to examine data about that item when it drops. Checking the database node is certainly one way. I might also be tempted though to add that data to the custom dragdata, for instance { owner = id-00002 }, so that a drop target can read metadata, without needing to know all about the database structure.

At the end, I'm not sure having window controls with an intimate knowledge of part of the overall campaign structure is really a huge problem, but it's something I'm cautious about. Nonetheless, thanks for the feedback - it's given me food for thought about how to tidy up some nasty logic I've got in some of my shared window controls.