Finding the control identifier [solved]

Out of a value function callback, how do you get from the valueObject to its corresponding Control identifier?

I’m trying to change control attributes such as the color based on its value, but above is the link I’m missing to be able to call setColor for the right control

function getValues (valueObject, value)
    local message = valueObject:getMessage ()
    local control = valueObject:getControl ()
    print ("Control Name:" .. control:getName ())
    print ("Control ID:" .. control:getId ())
    print ("Device Id: " .. message:getDeviceId ())
    print ("Type: " .. message:getType ())
    print ("Parameter Number: " .. message:getParameterNumber ())
    print ("Current value: " .. message:getValue (default))

edit: the code snippet has been edited by @martin


Thank you @mIIwaukee, this info was very useful indeed! It helped me a lot :pray:

:warning::warning::warning: BUT… beware! :warning::warning::warning:

The forum software here seems to automatically change 2 dot/period/full stop characters (henceforth referred to as ‘dot characters’) to a special ellipsis character that the LUA editor does not understand!

So if you copy and paste the above code into the online LUA extension editor, it will fail to run, and it won’t tell you why! I wasted a good 30 minutes trying to figure out what was going wrong with, what appeared to be, well formatted LUA code!

But it wasn’t well formatted after all, because the forum software had automatically replaced ‘..’ with ‘…’, and the LUA interpreter gave up as a result :man_shrugging:

LUA needs two individual dot characters to join separate strings in a print statement such as this:

print ("This is a well formatted" .. " LUA print statement")

But if you’re posting on this forum and you happen to type ‘..’ (two dot characters), the forum software will automatically substitute a fancy ellipsis character instead, thus breaking your code example!

print ("This is NOT a well formatted LUA print statement")

@martin Please take note! Thanks both.

Forum also changes ‘--’ (LUA comment) to ‘–’ which LUA interpreter also doesn’t understand.

@benstat thanks for spotting this. I will adjust the app editor to validate the source code that non-ascii characters are reported.

With this in mind, I strongly suggest that code snippets should be marked as code in the forum message editor:

also, I will edit the posts that do not have it to prevent the forum from spreading the non-working code.