Add a deliberate bug to your code whilst fixing it

[Malcolm_Myers]

Sometimes, when debugging code, I may force a situation, e.g. force a boolean to be TRUE or FALSE, or force a For Loop to only run once. Once I have made the fix I then forget to reverse my changes and run my code. Or, even worse, create an executable and send it to a customer. Doh!

Could we create a primitive, in the shape of a small bug, that I could drop in my code at the point where I force the code? Then, when I come to run a popup asks "Run with bug?" This would allow me to debug my code, but would also remind me to undo the deliberate bug before I run the code for real or try to create an executable.

[thols]

Just use a conditional disable structure in a sub-VI that you place where you want the "bug". Maybe even in a vim so you can connect anything to and from it. Then you can enable the bug-state from the project.

What should happen when the "bug" occurs? What should be affected? The definition of this "bug" is quite vague. Should an error be set on the error wire, should the VI crash, should the user get a message that says "bug", should a calculation return another value...?

[wiebe@CARYA]

My problem with a conditional disabled structure is that it forces a recompile, and SCC change. The benefit is the debug code is actually removed.

I often put the code in a case structure and wire a control to it (not connected to the connector pane!). When debugging, I set the control to true, but after a reload or build the value is false, and the debug code is not executed.

Can't you just make a reentrant VI, that pops up the message, and asking (once) if the debug code should be executed? Give it a bug icon, and the idea as I understand it is there:

(You'd need a 4-button dialog of course, to support No (don't ask again).

This would work nicely combined with a conditional disabled structure (to turn it off in RTE and\or based on a global).

This could get messy when used with different kind of reentrant VIs, but a function would have the same issues.

[Malcolm_Myers]

I'm sure there are ways to engineer this, but they all add code and are time consuming. I was thinking more along the lines of an active comment, i.e. quick drop a "bug icon" onto your block diagram (< 1 second). Play around with your code. Then you forget you made the changes (ok, maybe just me :)) and you try and run the code with your forced conditions still in place. LabVIEW immediately picks up the bug icon and asks you to deal with it. It's half-way towards a broken run arrow, your code is 'broken' but it still runs and it takes seconds to return to normal, just delete the bug icon.

[Malcolm_Myers]

I solved this myself. I created Bug.vi that pops up when it runs and then a pre-build action to search for Bug.vi when I build. Works a treat.

[wiebe@CARYA]

The gest of this idea is to include such a function in LabVIEW.

I do agree that some things should be added to LabVIEW. even if it can be (and has been) done by anyone.

This idea is probably one of those that solve issues most of us have already learned to work around.

[Malcolm_Myers]

I agree Wiebe. In the past I have written plenty of code for myself that then seemed to be shipped with later versions of LabVIEW. Clearly I wasn't he only person with the same problem!

Thanks for all your comments and ideas.