Darren's Occasional Nugget 06/12/2023

[Andrey_Dmitriev]

---

@altenbach wrote:

---

During execution of that tool, LabVIEW sometimes becomes unresponsive for certain moments. If I click in a VI in file explorer during these stalls, ...

---

Exactly same for me. During long batch build invoked from my own custom made tool there are the moments when LabVIEW looks like "frozen" and not responding, but everything works fine in the background. Probably Windows messages are not processed for some time, and the LabVIEW "hangs", who knows. This not disturb me much, I just taking a coffee break during building.

[wiebe@CARYA]

---

@Andrey_Dmitriev wrote:

---

@altenbach wrote:

During execution of that tool, LabVIEW sometimes becomes unresponsive for certain moments. If I click in a VI in file explorer during these stalls, ...

---

Exactly same for me. 

---

Maybe they based behavior on the 'stop' button in the project loading dialog? 😋

Oh wait, that hangs LabVIEW forever (which is probably why the button is called 'stop').

Pressing 'stop' was the first thing our hired intern tried in LabVIEW after an internship done in Python... Not a good first impression.

Please (please, please) remove the button or make it work properly.

(Sorry for the rant, it is remotely on topic, as load times get long (infinitely long) when pressing stop.)

[Dataflow_G]

---

@Darren wrote:

#2: Remove circular dependencies

A VI in First.lvclass calls a VI in Second.lvclass. A VI in Second.lvclass calls a VI in First.lvclass. Assuming one class doesn't inherit from the other, this is an example of a circular dependency. The more circular dependencies you have between libraries (.lvlib and .lvclass), the longer it will take for your code to build. For identifying circular dependencies, I have heard that the LabVIEW Class Dependency Viewer can be useful, although at present, I have not tried it myself.

---

The VI Hierarchy window can also be used for viewing circular dependencies, illustrated by curved dotted lines between the offending controls / VIs (KB article: Dotted Lines in LabVIEW VI Hierarchy Diagram)

[Andrey_Dmitriev]

---

wiebe@CARYA wrote:

---

behavior on the 'stop' button in the project loading dialog? 😋

Oh wait, that hangs LabVIEW forever (which is probably why the button is called 'stop').

Pressing 'stop' was the first thing our hired intern tried in LabVIEW after an internship done in Python... Not a good first impression.

Please (please, please) remove the button or make it work properly.

(Sorry for the rant, it is remotely on topic, as load times get long (infinitely long) when pressing stop.)

---

Did you mean this one:

?

Strange, it works for me... once pressed then the following dialog appear:

and all three options are functional (usually). Using this time to time when occasionally opening "wrong" project and do not want to wait until fully loaded before choosing the right one. May be an issue with particular project (for example with circular references, may be).

[rolfk]

---

@Andrey_Dmitriev wrote:

---

wiebe@CARYA wrote:

---

behavior on the 'stop' button in the project loading dialog? 😋

Oh wait, that hangs LabVIEW forever (which is probably why the button is called 'stop').

Pressing 'stop' was the first thing our hired intern tried in LabVIEW after an internship done in Python... Not a good first impression.

Please (please, please) remove the button or make it work properly.

(Sorry for the rant, it is remotely on topic, as load times get long (infinitely long) when pressing stop.)

---

Did you mean this one:

?

Strange, it works for me... once pressed then the following dialog appear:

and all three options are functional (usually). Using this time to time when occasionally opening "wrong" project and do not want to wait until fully loaded before choosing the right one. May be an issue with particular project (for example with circular references, may be).

---

I think he meant the application builder progress dialog. It works, but if you have a large project compiling and abort it mid way, it takes forever, and I mean forever, to actually show that dialog. I have found that letting it just built the whole bunch anyways, even though I know I messed up and need to fix something before the build is good is usually actually faster than pressing the stop button and waaaaaaaaaiiiiiiiiiiiting for it to come with the actual dialog.

But aborting a load is usually also resulting in a guru meditation session (or a coffee break if you are more into some drugs) 😁

[MichaelAivaliotis]

The hierarchy view to detect circular dependancies is nice tip.

[wiebe@CARYA]

---

@Andrey_Dmitriev wrote:

---

wiebe@CARYA wrote:

---

behavior on the 'stop' button in the project loading dialog? 😋

Oh wait, that hangs LabVIEW forever (which is probably why the button is called 'stop').

Pressing 'stop' was the first thing our hired intern tried in LabVIEW after an internship done in Python... Not a good first impression.

Please (please, please) remove the button or make it work properly.

(Sorry for the rant, it is remotely on topic, as load times get long (infinitely long) when pressing stop.)

---

Did you mean this one:

?

Strange, it works for me... once pressed then the following dialog appear:

---

I never get those options. LabVIEW just freezes forever.

But... You are using a newer version, so it might have been fixed.

It might also have to do with the projects, mine are usually quite large and have 100-400 classes, in 20-100 hierarchies.

[wiebe@CARYA]

---

@rolfk wrote:

---

@Andrey_Dmitriev wrote:

---

wiebe@CARYA wrote:

---

behavior on the 'stop' button in the project loading dialog? 😋

Oh wait, that hangs LabVIEW forever (which is probably why the button is called 'stop').

Pressing 'stop' was the first thing our hired intern tried in LabVIEW after an internship done in Python... Not a good first impression.

Please (please, please) remove the button or make it work properly.

(Sorry for the rant, it is remotely on topic, as load times get long (infinitely long) when pressing stop.)

---

Did you mean this one:

?

Strange, it works for me... once pressed then the following dialog appear:

and all three options are functional (usually). Using this time to time when occasionally opening "wrong" project and do not want to wait until fully loaded before choosing the right one. May be an issue with particular project (for example with circular references, may be).

---

I think he meant the application builder progress dialog. It works, but if you have a large project compiling and abort it mid way, it takes forever, and I mean forever, to actually show that dialog.

---

That one usually works, although I rarely use it. Sometimes you need a cleanup.

[Kyle97330]

---

@Darren wrote:

#2: Remove circular dependencies

A VI in First.lvclass calls a VI in Second.lvclass. A VI in Second.lvclass calls a VI in First.lvclass. Assuming one class doesn't inherit from the other, this is an example of a circular dependency. The more circular dependencies you have between libraries (.lvlib and .lvclass), the longer it will take for your code to build. For identifying circular dependencies, I have heard that the LabVIEW Class Dependency Viewer can be useful, although at present, I have not tried it myself.

---

Question regarding this:

If I create a lvlib library, and put 1 or more classes in it, does that count as a circular dependency in that it would make EXE builds take longer?

Example 1:  A lvlib with one class in it.  Technically each of these is a library and loading one loads the other.  Is this "circular"?

Example 2: A lvlib with multiple classes in it, not dependent on each other apart from being members of the same lvlib.  But loading the lvlib loads them all, which does seem circular.  Is this actually circular?  Does it make it "less circular" if the "Remove unused members of project libraries" option is checked in the build and only a subsection of the classes are used?

Example 3: A lvlib with multiple classes in it, but this time some of the classes have parent-child inheritance and/or are Interfaces that the others implement.  Does being in a lvlib together make them now have a circular dependency, where they previously had a 1-way dependency?

[Darren]

I figured I would create somes libraries with classes with VIs that call each other, open the VI Hierarchy Window, and see what it draws:

It looks like for your 'Example 1' the VI Hierarchy window doesn't consider that circular. For 'Example 2', all classes in a project are loaded into memory when you open a project, so the library(ies) that own those classes aren't really going to matter. If I'm understanding your 'Example 3' correctly, this is the same scenario.

As you can see from the VI Hierarchy window, you'll get circular dependencies (the dotted lines between VIs) when those circular relationships are outside of ownership relationships.