VIs menu reacting too slow

[MartinP]

Nope, thats probably not it. I prefer always per default to use controls and indicators from the Classic menu, so the number of System controsl are minimal here.

Martin

[Yamaeda]

---

@MartinP wrote:

We have now tested the program under LabVIEW 2025 Q1, with 32 and 64 bit version of LabVIEW and the problem is still there.

I have installed a nVidia T1000 to get access to a stronger GPU, but that did not help either.

We see that when scrolling down on the LV GUI, so all objects are not visible on the screen anymore, then the problem is gone.

So it seems clear that the GUI I have created contains to many objects/controls/indicators for LabVIEW to handle in a good manner.

The problem has been escalated even one step up the knowledge chain in NI. I'll report here what feedback I get.

---

I remember some old issue where overlapping controls, especially if transparent caused 100% cpu and sluggish performance (probably due to some cascading redraw), could that be related? I personally had an issue when i manually hid and showed a number of controls (instead of grouping them into a cluster) and the error wire wasn't wired causing it to try and do it in parallell causing some lock up. In that case just wiring together the property nodes solved it.

[thols]

---

@Yamaeda wrote:

---

@MartinP wrote:

We have now tested the program under LabVIEW 2025 Q1, with 32 and 64 bit version of LabVIEW and the problem is still there.

I have installed a nVidia T1000 to get access to a stronger GPU, but that did not help either.

We see that when scrolling down on the LV GUI, so all objects are not visible on the screen anymore, then the problem is gone.

So it seems clear that the GUI I have created contains to many objects/controls/indicators for LabVIEW to handle in a good manner.

The problem has been escalated even one step up the knowledge chain in NI. I'll report here what feedback I get.

---

I remember some old issue where overlapping controls, especially if transparent caused 100% cpu and sluggish performance (probably due to some cascading redraw), could that be related? I personally had an issue when i manually hid and showed a number of controls (instead of grouping them into a cluster) and the error wire wasn't wired causing it to try and do it in parallell causing some lock up. In that case just wiring together the property nodes solved it.

---

Yes, I got that too once. I think I had a button on top of a graph and if I recall correctly I did not do things in parallel. I wonder if that has improved in the last years.

Too see if the cause is just that you have many controls visible, create a new VI with as many controls, not overlapping, and see if the same thing happens. 

[Yamaeda]

Selecting a bunch (all?) of the front panel objects and use Horisontal/vertical Compress from the Alignment menu should make sure none is overlapping.

[MartinP]

My problematic program runs at 0.2% CPU, so it does not seem to be connected to the same problem. I do not have much overlapping controls, but I do have a lot of controls and indicators spread over many pages of a tabulated control.

Right now I will just wait send see what third row of support (escalated twice) at NI are able to come up with here.

Martin

[MartinP · Accepted solution]

The problem is solved, and it was a bug  (Bug# 3090358).  But it was rather well hidden, so I understand the people at NI (third-line support) needed some time to investigate this one. 

It appears that the problem was due to a saved state in the VI, which was originally created in evaluation mode. This state was not cleared when the VI was saved in a licensed edition, leading to bounds recalculation for all FP objects when hovering over the menu bar.
It is supposed to be fixed in future versions. If anybody should be so unlucky to end up with the same problem, they need help from NI to remove the saved state.

Thanks for all feedback and tips during this investigation.

Martin

[Yamaeda]

What states can exist that's unique to Evaluation? o.O