Can I drag items with Custom Data onto the HotKey bar ?

[phantomwhale]

Hi,

Having just put in some rather nice functionality onto my dice fields, all stored in the custom fields, I have found something odd - I can no longer drag them onto the hotkey bar.

Well, that's not true, I CAN drag them onto the hotkey bar, but dropping them seems to do nothing. I've even written a small handler to intercept all "onHotKeyDrop" events, and it doesn't record anything being dropped onto the HotKeyBar at all ?

Is there anyway this dragdata can be captured in the HotKeyBar ? Or must I undo all my good work ?!? (it's the weapon shooting function, so people are gonna want to hotkey it). Guess which answer I'd prefer to hear :)

Regards,
Ben

[phantomwhale]

Well, I've written a workaround to the above issue (hotkey's can't store custom data), but would still be interested to know if they definitely can't, and if not, if there might be plans to let them do so in the future ?

In the meantime, I have lent on the "StringData" component which can be stored in the hotkey, and written all my custom data fields in a "comma seperated name=value pair" format.

For example : "name1=value1,name2=value2"

Then I have written a library function to parse them from any dragdata object, and write it into the "CustomData" component as a table instead, so in the example above it would parse the string and generate the table : { name1 = value1 , name2 = value2 }.

It then saves this table to the custom data component and blanks the string data component out (required for recursive functions).

The code for this is below :


-- Utility function to convert CSV name=value pairs into custom data
--
-- This is used to get round the limitation that the hotkey bar cannot store custom data
--
function convertStringDataToCustomData(draginfo)
if draginfo and draginfo.getStringData() ~= '' then
draginfo.setCustomData(draginfo.getCustomData() or {}) -- ensure custom data initialised to a blank table, if required
local s = draginfo.getStringData() .. ','
local t = draginfo.getCustomData()
local fieldstart = 1
repeat
local nexti = string.find(s, ',', fieldstart)
local nvp = string.sub(s, fieldstart, nexti-1)
local divider = string.find(nvp, '=')
if divider then
local key = string.sub(nvp, 1, divider-1)
local value = string.sub(nvp, divider+1)
t[key] = tonumber(value) or value
else
local msg = { font="systemfont", text="Unrecognised drop data in string '" .. s .. "'"}
ChatManager.addMessage(msg)
break
end
fieldstart = nexti + 1
until fieldstart > string.len(s)
draginfo.setStringData('')
end
end

Like I say, a workaround for now.

[StuartW]

I think that is the way to make it work. I ran into the same problem with the RMC ruleset and had to create table-to-string and string-to-table functions to store info on hot keys. The alternative is to store the actual table data in the db or registry and store a path to it in the hot key (although I've never used that method myself). If I recall correctly, there was a limit to the length of the hotkey string data, but I think that was fixed some time back. JPG may know better.

Stuart

[Moon Wizard]

Yes, the hot keys are simply triggers.

Basic types built into FG (string, number and dice) are automatically handled by the FG client. Anything that requires custom data or custom data types currently need to be handled completely by the ruleset using the onHotkeyDrop and onHotkeyActivated handler functions.

I've actually run into the same issues with the 4E (and 3.5E) rulesets. At some point, I plan to either build a subsystem within 4E and/or add new FG capabilities to make this easier. However, it's not in the current development schedule.

Regards,
JPG

[phantomwhale]

Basic types built into FG (string, number and dice) are automatically handled by the FG client. Anything that requires custom data or custom data types currently need to be handled completely by the ruleset using the onHotkeyDrop and onHotkeyActivated handler functions.


I did investigate this route, but upon dropping a dragdata object with non-nil custom data onto a hotkey, the "onHotkeyDrop" callback function I'd created didn't seem to ever be invoked ?

I notice that some more complex elements (such as the wound modifiers or ammo trackers in Savage Worlds) have their own "onHotkeyActivated" listener to implement more complex hotkey behaviour post-drop. Although whilst the functionality is non-standard (e.g. thus requires custom code) there is still no custom data involved in the drop.

So if the hotkey's actually supported the drop of dragdata, I would be more than content to code away the two handler methods to implement the remaining functionality. But right now, there are no handler methods being invoked on drop, so therefore it's impossible to use such dragdata objects in the hotkey bar no matter how much code I might write.

Is this a correct assessment ? And would even "supporting the storing and recall of custom data" on the hotkey bar (similar to the string data - it doesn't know what to do with it, but it will pass it onto other windows on invocation / redrag) be a possible development item at any stage ?

[StuartW]

It's too long since I last coded this, but I think you might need to set a custom type using setType. Custom types, and multiple dragdata slots, are preserved by the hot key handler, iirc, and most of the scripting then revolves around onHotKeyActivated. I also seem to recall that you do this stuff from custom script modules, and you may need to register your handler using onHotKeyActivated = myHandler, or something!

Sorry I'm not much help, but it has been 18 months since I last played with this, and I'm away from my development machine and hence can't check back on the code.

Stuart

[phantomwhale]

It's too long since I last coded this, but I think you might need to set a custom type using setType. Custom types, and multiple dragdata slots, are preserved by the hot key handler, iirc, and most of the scripting then revolves around onHotKeyActivated. I also seem to recall that you do this stuff from custom script modules, and you may need to register your handler using onHotKeyActivated = myHandler, or something!

Yep - that's the trick. Savage Worlds has a main event handler which farms out the onHotkeyActivated event to various functions depending on the type, like so:



-- Register hot key event
function onInit()
Interface.onHotkeyActivated = onHotkey;
end

-- Dispatch event types
function onHotkey(draginfo)
if draginfo.isType("custom1") then
handleCustomOne(draginfo);
elseif draginfo.isType("custom2") then
handleCustomTwo(draginfo);
end
end



But again, this doesn't quite address the base of my problem, that being that a dragdata object with the "custom data" part set does not seem to able to register at all when dropped onto a hotkey slot.

Therefore no onHotkeyDrop method is called... and certainly no onHotkeyActivated, as there is never a hotkey to activate !

[StuartW]

I think I coded the RMC (and BRP) rulesets so that the info for the hot key was created when the drag started, not when the drop happened. The drag object needs to have both custom data and your string equivalent/alternative. There is a definite precedence over the various types (string, dice, number and custom) and there is also some shared top-level information (I think description was one of those). Getting the right combination of the data types, in the right slots took me a few tries. If you have the BRP ruleset, you might want to give it a look (it is used for skill rolls, because they link back to the underlying skill and don't just use the current value).

Stuart