How to properly restrict label for parameter?

I have a control that can map to any given parameter, and a label that the user can edit rather than use the control. I’m having a problem trying to restrict the values of the label to what the currently mapped parameter accepts. For labels attached to known parameters, I can just use my personal knowledge of the parameter itself to write code that restricts it, but I need a generic solution.

When I use getFloatValue() on the text the label reports, it gives me 0 if the result is garbage. For parameters that don’t accept 0, I can detect that and reset the label to its previous text. But when 0 is a valid value for the parameter, typing in garbage like “xyzzy” results in the parameter being set to 0.

And of course the parameter might use strings to display its values (such as “Major” or “Minor” for a Scale parameter…

Is there any to detect that the value the user typed into the label is not valid for the given parameter? I don’t see any parameter or label function that allows me to detect that. A virtual function in the AudioProcessorParameterWithID or AudioProcessorParameter class would be nice, since the parameter knows what it will accept, and could override it. There is the textToValueFunction, but that requires the AudioProcessorValueTreeState::Parameter type, which is private to AudioProcessorValueTreeState. Is there some other way to access that?

Thanks!

Hmm… even if I could access the textToValueFunction, I’d have the same problem for parameters that accept 0 as a valid value, because the String’s conversion from text to a float/int returns 0 when the parsing fails.

I’ve seen another discussion here that basically says there is no way to detect that the conversion fails, in general.

But it seems to me that two changes could detect that: one, if the underlying language call(s) to convert the string to a number failed, that should be detectable; and two, if that succeeds, then a range check could be performed and report out-of-range as a failure as well.

Nope, I was wrong. The strtod_l() function itself returns 0 if it fails, so my assumption is incorrect. The underlying conversion routine will return 0, so that’s what the String and thus the parameter will return. Bummer. This makes my parameters that accept 0 behave differently from my parameters that do not accept 0.

It looks like I can create a TextEditor object to be used by my Label when editing, and I can set an InputFilter on that, which will I can customize to restrict the string as it is entered. That might be the best solution for me.