I have to add, for future reference, please report issues like this rather than find code workarounds.
Here is the link to my nodes for reference:
The effected nodes as I observed so far are the scheduler and the time change nodes.
Thanks - but to save me digging through to find what TypedInput is having an problem, can you give me some steps to recreate ? Which field should I be looking at?
Experienced same with the node-red-contrib-ui-state-trail. The order of commands matter. typedIput("value", value) and then typedinput("type", type) ends with the empty value field when in ediatableList the creation runs on existing rules. It wasn't problem previously.
@hotNipi again, I have to ask, which field should I be looking at? I have got fixes lined up for this, but want to test it against more nodes.
Your scenario is a bit different to the others.
You are defining your TypedInput with the types 'bool', 'str', 'num'. Because you don't tell it what to set its type it, is assumes you want 'bool'.
A few lines later you then set the value. But as the type is still 'bool' it is expecting true/false values. As you are setting the user-provided 'string' value... which doesn't match any of the valid options, it doesn't accept it.
Previously this worked because it let you set invalid values, getting the internal state inconsistent, but then 'resolved' by calling 'type' to change it to a 'str' type input. The only fix I can see is to not have the TypedInput validate you are setting valid values... which isn't ideal.
I will look at what we can do - it isn't my intention to break this. Moving forward, I can recommend some changes to how you are using the TypedInput.
-
when you are creating your TypedInputs and you already know what type the field should have, make sure you set the
defaultproperty in the constructor function call. -
if you know the value the input should have, set the value of the
<input>before you call the TypedInput constructor
Doing it this way avoids the need to explicitly call the type or value functions of the input after constructing it.
I believe taking those two steps will avoid this issue and be 100% backward compatible (ie you shouldn't stumble over other issues doing that with older versions of the TypedInput).
Thank you. Clear and constructive as always 
@hotNipi @jens_rossbach @Hypnos
I believe I have fixed the issues with the TypedInput initialisation. It should behave consistently with pre2.1.
However please do see my previously reply above for best practices on initialising the TypedInput correctly.
The good news is I know have added about 20 test cases (albeit ones that have to be manually verified) to the Node I use to check the behaviour of the TypedInput across a wide range of initialisation/setting type/setting value sequences.
We will get 2.1.2 published tomorrow morning.
2 Likes
@knolleary Sure, here are some details.
For the scheduler node, please look at file "nodes/scheduler.html". The affected widget is outType which is first declared at line 286.
For the time change node, please look at file "nodes/change.html". The affected widget is property which is first declared at line 280.
One additional information: The issue only happens for the "msg" type but not for e.g. the "flow" and "global" types.
Thanks @jens_rossbach - I've just released 2.1.2 that should fix all of the issues raised here.
I tested it with both of your nodes and the others mentioned (although I never did find out which nodes @Hypnos was referring to).
If you still see any odd behaviours, please raise them as issues. As I've said, its important that we don't regress behaviour - even if we do update the best practices to follow.
My nodes are the GitHub - rdmtc/node-red-contrib-sun-position: This is a ultimate Node-Red Timer, Sun, Moon and Blind flow control.. Since I am currently on vacation, I unfortunately cannot test it.
I tested it also on my side and can confirm that the issue is solved.
About the other problem (I know it's just a cosmetic one) with the spinner widget: do you have an idea what happended? The function node and inject node show the same: the spinner widget has a smaller height and width and the content has no padding to the borders which does not look so nice.
This is how it looked on older Node-RED versions:
This is how it looks since Node-RED 2.1.x:
Before, the spinner widget had the same height as the typedInput widget or normal input fields and was also wider. Now it looks quite compact.
The spinner should be back to the correct appearance with NR 2.1.3
1 Like
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
