Receive nodes wont get red when sender missing

[guest]

old behaviour (< 35.1) was: receive node will get red when selected sender is missing (renamed or deleted)

since 35.1 : node just shows NIL as receive string but wont turn red.

→ harder to debug. also sender renaming is hell when you dont remember where you placed the according receives in your project…

sr_not_red.v4p (2.0 KB)

[gregsn]

under investigation. Thanks for reporting! Also good to hear that red enums are actually perceived as a feature in some rare cases… ;)

[velcrome]

@gregsn
To me red Enums have not only been

• early warning signs with S+R problems,

but also

• a visual hardware list that auto-checks all the devices availability
• a project’s life line when upgrading to newer versions, especially with diffff.xml absent or incomplete
• restless guides while refactoring patches with vvvv-Message

There I say it: They are not only “a feature in rare cases”. When red, they visually highlight that some user-based patch assumption has not been met, or said differently, they spell out the name of an expected item that is currently not available on your system.

[gregsn]

thanks velcrome for your assuring words!
we’ll work hard to get your nodes red again.

[sebl]

when touching that code… maybe it would be possible to sort the enum lists alphabetically!

[gregsn]

upcoming alpha comes with these changes:

• bug fix: invalid enum entries get red again
• s/r channels sorted in pop up
• r nodes don’t forget last sender even when sender got deleted
• ex9 effect: shader technique not red even when null

edit: alpha is up