Case structure constants for every case

[NiklasN91]

Hi there,

I want to suggest a function for case structure tunnels:

Create constant in every case

If you have big case structures, and want to add a tunnel with constants inside, you have to add a lot of constants. This

could be avoided if you could add a constant for every case and then only adapt the value.

[altenbach]

Should each case have a different constant? If most are the same, you could place the constant before the case structure and use a linked input tunnel to get that constant except in cases where the wiring is different.

If all are the same, the constant belongs outside and the case.

You could also create the constant first, then duplicate the case. Many times, the "use default if unwired" is also an option.

There is also this idea which might help.

Somehow, creating a constant seems to be a very small fraction of overall code writing. To create a constant with a new value requires only a small number of clicks (right-click..create constant...type value). Having to later enter new values into existing constants for all other cases is more dangerous because you might accidentally miss one of them. If you create and modify constants at once, you are sure that you have visited all cases after the tunnel turns solid.

[JimChretz]

With experience I manage to avoid this situation by trying to have good programming habits.

I had this issue with the enum for the state machine, when your default value (0) is set to your idle state, you can set your tunel to use default if unwired...

For a boolean I try to make my False value to be default, then I only put the True constants where I need it.

Other than that, I don't have much this issue.

[Mr._Jim]

Alright, maybe I'm foolishly speaking up on this one, but I have definitely run into this when writing some complex controls, where I've got numerous DBL values that vary depending on different states.  Right clicking on tunnels gets really old really quickly.  Sometimes this also happens when you've inherited someone else's architecture and you've got to make do rather than rewrite all umpteen cases.

Now granted, I'm not writing as much code of this type anymore since the vast majority of my code is now OO, but still...  I could see this being useful.

There's definitely a case to be made (no pun intended, har har) for using default Boolean values and default enum values on output tunnels.  Those practices will definitely save a lot of time and those use cases are probably the ones I run into the most.

Niklas, if it were me, I wouldn't hold my breath on this idea coming to fruition, if only because it'll be tough to pick up enough of a "kudos" following.  If it were me, this is the sort of thing I'd make a quick drop plugin for.  I've had a couple of other uncommon practices due to unique design techniques that I've scripted myself with a quick drop plugin, knowing full well that few other users would find my plugin useful.

For what it's worth...

Jim

[AristosQueue (NI)]

Speaking as a user of LV: I like this idea. It's not for everyone, but if it can be done in a way that doesn't muck with the user interface too much, it seems (rarely but just often enough) useful.

As a R&D member: we'd be careful adding this generally but it is certainly doable.