LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

Easy Access Button to Enable/Disable Debugging

One of the quickest (and easiest to forget) methods to improve performance of your VI is to disable debugging.  It requires a trip down the VI properties to get there, however.  I propose adding a button on the BD alongside the other debugging buttons to Disable and Enable Debugging.  

9 Comments
Knight of NI
Seems Obvious!  like any great idea. 
Knight of NI

This needs to be weighted against further cluttering the interface, but I would probably use it occasionally. 😉

 

However, it's not too important. During development, debugging is probably desired, and once the application is built, debugging is gone anyway. 😉

 

 


LabVIEW Champion. It all comes together in GCentral GCentral
Active Participant
IMO, the toolbar is a great place for putting tools, but not really for toggling persistent settings of the VI.
JKI Blog
Trusted Enthusiast
Jim, good point. So does that mean the button should be a temporary override, or a persistent setting? I might vote for a temporary override (reset once VI leaves memory), but I would not want a persistent setting on the toolbar. Honestly, I rarely disable debugging because I never think about it, and any benchmarking I do is going to be relative, not absolute. But if it were on the toolbar, I may think to use it more?
Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
Active Participant

Great idea.  In fact, why is the debug setting saved with a VI anyway?  And why does it default to enabled?  It makes much more sense to have debugging always disabled (i.e. VIs always saved with non-debug code), but VIs are recompiled for debugging if a button is pressed in those VIs you're looking at - they're necessarily open anyway.  If the next version of LV was set like this, 90% of programmers would think "Wow - this version is SO much faster!!"

Member

"[...]It makes much more sense to have debugging always disabled[...]"

 

What happens, if you debug your VI and you step into a Sub-VI, where debug is disabled?

CLD
Proven Zealot

>>What happens, if you debug your VI and you step into a Sub-VI, where debug is disabled?

 

That is a nice point to think........

Knight of NI

> What happens, if you debug your VI and you step into a Sub-VI, where debug is disabled?

 

Nothing. The subVI is most likely fully debugged and of no interest in this regard. 😉


LabVIEW Champion. It all comes together in GCentral GCentral
Trusted Enthusiast
Trusted Enthusiast

I concur but in the grand schele of thing, we need more.

 

Offer a column in the project explorer that allows doing it:

- per VI

- per Folder

- for All VIs

- add you own options here, like all dependent subVIs, etc

 

In particular, I see the need for "temporary groups" of debuggable VIs defined as a list (or in the column spirit of the idea above). Check it, uncheck it. Save it, modify it, etc, etc.