CTRL-SHIFT-Run should display progress windows the same as MASS COMPILE.

[gksloane]

When you mass compiled, all VIs in the directory tree get recompiled. When you hold CTRL and SHIFT and click the run button on a VI, it forces a recompile of all VIs in the call chain. 

However, when you CTRL-SHIFT-Run, all you SEE is a busy mouse; it would be really nice if you could get a popup windows (the same as when you mass compile) showing what's going on, and giving options to cancel... it would also be nice to be able to specify a log file and how many VIs to cache, same as with mass compile...

It could be the same popup with a different title...

[AristosQueue (NI)]

Ctrl+shift+run is undocumented private functionality intended for debugging LabVIEW. It should never be needed in the course of normal operations.

[gksloane]

AQ -

1. I found out about it (ctrl-shift-run) from the website. Didn't know it was 'undocumented' - since it was documented. Somewhere. I forget where.

2. It is VERY useful. How about if you add an option to mass compile to have it grab only VI's from the calltree instead of the directory structure? We keep lots of 'dead legs' in our source tree (options not currently in the build) and we WANT to keep them there; but we HATE the fact that a mass compile makes us wait while it compiles the 10% we care about AND the 90% we don't.

3. And while we are at it, can we have a checkbox add to mass compile's options to force recompile even if the VI's appear up to date? That has fixed corruptions for us many many times...

Gary

[AristosQueue (NI)]

ctrl+shift+run doesn't do just the VI hierarchy. It does all VIs in memory that aren't currently running, including parts of the editor written in G. It's a very aggressive and potentially expensive operation that I don't recommend you do commonly.

LabVIEW 2019 and to an even greater extent LabVIEW 2020 goes out of the way to avoid compiling VIs most of the time. The IDE is way more responsive these days because of that work (especially if you use source-only on all of your VIs, something I cannot encourage strongly enough).

I don't know what corruptions is being fixed -- true LV bugs? or are you just talking user-caused crosslinking? If the former, please make sure to report those bugs so we can fix them.

Seriously, if ctrl+shift+run is something you commonly use, something is severely broken, and we should be investigating to figure out why you are having to do that.

[AristosQueue (NI)]

PS:

1. If your VIs are not using source only (called "unifile VIs"), then loading the top-level VI and doing File>>Save All is fully equivalent to doing mass compile for that hierarchy.
2. If your VIs are using source only, then mass compile isn't a meaningful operation most of the time. It does not have the same effect as mass compiling a unifile VI.

[RogerSaele]

---

@AristosQueue wrote:

Ctrl+shift+run is undocumented private functionality intended for debugging LabVIEW. It should never be needed in the course of normal operations.

---

Does go for ctrl+run as well?

Ctrl+run I use all the time when working with XControls. Very often after editing an XControl it will be slow when testing it. If I then ctrl+run the facade.vi it will go back to normal.

[AristosQueue (NI)]

That is true for ctrl+run as well.

I've never heard of any such issue with XControls. Assuming your observation is real, I suspect it is an issue of open panels, not of compilation.

I honestly cannot imagine any reason why recompiling would have any impact. If the XCtl is running, then it is already compiled, and compiling the same source code a second time should result in the exact same behavior -- and that's one "should be" that I haven't seen violated since we moved to the new compiler backend circa 2010.

But, after recompiling, LabVIEW unloads any open panels that aren't needed in memory. When a VI has its panel loaded, it does run slower because LV takes time to update the FP in case the user opens it. It may be that XControls are retaining their front panels improperly, and you forcing a recompile is giving them the opportunity to unload.

Wager: instead of hitting ctrl+run, close your project and reopen it. I bet that also fixes it. Obviously, hitting ctrl+run is way easier, so keep using the workaround if it helps you, but I think it is just working around a lack of optimization in XControls where we aren't eagerly throwing the panels out of memory.

[RogerSaele]

---

@AristosQueue wrote:

Wager: instead of hitting ctrl+run, close your project and reopen it. I bet that also fixes it.

---

You are right, it does.

[AristosQueue (NI)]

> You are right, it does.

Great. << Tone of voice is somewhat happy and somewhat sarcastic. Happy because it means it really isn't recompile that is fixing things, sarcastic because it confirms a bug in LabVIEW in my third-least-favorite area of the C++ code base: XControls.

If you can and don't mind taking the time, I'd like to have your code filed as bug report. I'll contact you with a private message.

[gksloane]

Ah Aristos,

You said "Ctrl+shift+run is undocumented private functionality intended for debugging LabVIEW. It should never be needed in the course of normal operations."

But... check out the documentation for CTRL-RUN and CTRL-SHIFT-RUN at https://www.ni.com/pdf/manuals/373353d.pdf... Look under "Execution".

In all fairness, that WAS published in 2010...

But this was published February 2020: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P82uSAC&l=en-US. "How to Force Recompile a VI"

GSloane (aka SBUS)

[AristosQueue (NI)]

a) Your PDF link takes me to a 404 Not Found page.

b) KBs are specifically for working around bugs.

c) Just because someone at NI mentions something doesn't make it a documented feature... I can't control what random NI person decides to put up any more than I can control what's posted to LAVA. It's not within LabVIEW shipping documentation anywhere so far as I know, and if I ever found it therein, I would immediately excise it (as would anyone else on the LV team).