"commenting out" parts of an event workflow, copying events



When designing various commands in an events workflow it can quickly become cumbersome to test several combinations of if else statements and so forth when you have to specify the entire series each time. It would be great to have an ability to “pause” (essentially temporarily commenting out) an if-else statement, for example.

Copying workflows to other elements would be great as well!

Don’t know what the ease of implementation of this sort of thing is, but for what its worth!



Hi @Asger, thanks for this! I’ll pass your input on to the team.

Definitely with you on the commenting out idea, it’s a pain when you’re e.g. trying a different workflow but aren’t 100% sure it’ll work and maybe end up going back to the way you had it originally etc etc… :disappointed:

Also copying sequences of actions and action configurations (selections for parameters etc) would be a huge time saver.

As you know we’re exploring some changes to the editor workflow so I’m optimistic you’ll see some significant efficiencies coming from that. :grimacing:


A tip from QA engineer @dhemrick that might be useful in lieu of editor efficiencies on this issue - if you have an If Else, you can prevent the content of the true section from executing by temporarily altering the content of the test, for example by testing If false == true (which can never be true). Not ideal but could save some adding/removing of actions…


Definitely wanna bubble this request back up. Even changing your logic values can cross you up, because you have to remember what the original logic should be, especially when you step away from a piece of code for an extended period of time. But if you could maybe just check a block of code, which would gray it out, then you know, all you have to do is uncheck it.


Thanks for bringing this back up Chris. Outside of Sue’s previous suggestion, we don’t have any updates that would add efficiency to our ability to turn on/off logical statements but I definitely see the value in this.

Just thinking out loud here as another workaround. I like Sue/Dale’s suggestion but I wonder if we take it 1 step further…

What if you encapsulate the entire “production level logic” in an if/else statement so that you can turn off the production level code and instead run a second set of logic that acted as a “development logic” set. You could duplicate the production level logic in the development set and make any tweaks you want to test out, etc. Then when it’s time to go back to the production level logic, you could adjust just the top-level if statement back to allow the app to go into it again?


Maybe even the trigger for that top-level if statement is a Device Variable. Then if you adjust the value of the device variable in 1 spot, it could trigger the “dev-mode” logic throughout the app?


If I’m understanding you correctly, that would be a great deal of code duplication.


If your logic statements are pretty built out, adding a layer and nesting them into it could require a large amount of rework to add a top-layer logic statement like that. I don’t know about duplication however since everything you have now would fall into the True pathway for instance. You just want to add a top-level switch to move the logic down a True/False path based on a device variable.

The issue is there’s no easy way to add a top level If statement to the current logic like it would be in a manual code environment unfortunately. That’s where the double-work comes into it all.