Methods for debugging VIs that modify controls

[littlesphaeroid]

I often write VIs that modify controls. For example, I may have a complex set of graph updates: update graph value, change color of the trace(s) based on pass/fail status, name the traces the legend, etc. What I tend to do is have VI input for the control reference, and on the BD, for debugging purposes, I will select the VI's local graph reference when the VI is running top level: 

This morning it occurred to me there may be better ways. For example, if I wanted to have this VI open while running the main VI, the local graph wouldn't be updated/styled. Maybe not a problem, I'm probably overthinking this, but checking instead if the reference's parent's FP is open might be even better, and updating either or both of the referenced controls could be useful.

Anyway, wondering how other people handle this sort of situation.

[mcduff]

You could check the Graph Ref and see if it is a valid reference. If not, assume you are running for debugging and use the local graph reference.

Top level usually works, except for asynchronously called VI's.

[littlesphaeroid]

I think checking for a valid reference is better in the sense that it's less costly than checking if the file is running top level! Thanks for that idea!

[littlesphaeroid]

Circling back on this, checking for a valid refnum is not ideal. If the VI is open and its caller passes in a control reference, that value persists when you attempt to run the VI standalone. So, I think my original method of checking if the VI is running top level is the best.

[mcduff]

Well, if you are running in debug mode, then why not just has a checkbox whose default is false. You know if you are running the VI standalone or not and can easily check the box. Not sure of the overhead in checking whether your VI is a top loop or not, would need to see your VI, but it will add code to your end product.

[littlesphaeroid]

Thanks, mcduff, you're right, that's a good solution!  I went the more automated route because if you don't flip the switch back or close the VI so the switch assumes its default (nondebugging) state, and then run the calling VI, you won't get the expected result, and this can lead to a lot of hair pulling. 

Ultimately this check can be removed when the VI is fully debugged, and especially if in a time-critical loop, but it's amazing how often I go back and fix or improve these things.