Detecting which field (object, not UI)

[arctic stream]

I made the Editable objects addon, and right now I'm using the field's tooltip to smuggle the ID of the editted field

I know it could probably be done with global functions, because I did it with the buttons. Maybe there was a better way?

[halcyon adder]

there's always a better way - as I haven't seen the mod could you show code showing how you're doing it currently?

if you just want to know when the name, description or gm notes of an object was changed - then there's only one way really: check every frame against the last frame's value

and if memory serves me correctly, the information on the object is only set when the ui is closed or the field is deselected (by selecting a different field, for example)

[arctic stream]

So I create an input with

  ...,
  input_function = "edit",
  ...
})```

and the edit function is:

function edit(obj, ply, value, selected)
    for k, v in pairs(obj.getInputs()) do
        if (string.sub(v.tooltip, 1, 1) != "D") then -- If it starts with D, its a decal, not a field
            local spl = split(v.tooltip,";")
            if (#spl > 1) then
                fields[tonumber(spl[1])].value[tonumber(spl[2])] = v.value
            end
        end 
    end
    updateSave()
end```

Since I have no info as to which field was just editted, I loop through all of them and update the values according to their tooltip

The values are stored in the table 'fields'. Each field has its color, font size, array, etc, and it has a 'value' table, in which I store each value of the array

for example, if you had a score card, you can have a single field, but if that field is set to have an array of 5,8 then it has 40 values inside of it, one for each 'sub field', if that makes sense

I guess I could have a table that stores each input and its corresponding fieldID and arrayID.

Well, I have a solution that seems to work

[arctic stream]

Ok, I fixed it. I added a 'lookup' table that stores each field's IDs according to their field index (increasing a counter as I create them so it lines up with their field index), and use that to update them

[halcyon adder]

inputs = {
  { -- input 1
    name = "Edit",
    ...,
    input_function = "edit",
    ...
  },
  { -- input 2
    name = "Notes",
    ...
  },
  -- etc
}

createdButtonCount = 0
function onLoad()
  createInputs()
end

function createInputs()
  for i,inputTable in ipairs(inputs) do
    local inputFunctionName= "inputFunction"..i
    local func = function(obj, ply, value, selected)
      edit(obj, ply, value, selected, inputTable)
    end
    _G[inputFunctionName] = func
    inputTable.click_function = inputFunctionName
    self.createInput(inputTable)
    inputTable.index = createdButtonCount -- for .editInput
    createdButtonCount = createdButtonCount + 1
  end
end

function edit(obj, ply, value, selected, inputTable)
    if inputTable.name == "Edit" then
      print("edit table!")
    end
    -- ...
end

@arctic stream

I use this for buttons too - it lets you store more information in the table, and access that within the called function

[arctic stream]

Yes, I'm using that for the buttons in checks and increment/decrement counters

I could have used that aswell, for some reason I feel like reducing the amount of global functions is a good thing, even though I have no evidence for that

If the lookup table method hadn't worked, I would have definetly gone the global function route. Thanks for the help!

[halcyon adder]

a global function is just a global reference - no real harm if the key is long/unique enough