opening VI in edit mode gives 60% CPU usage

[_Faust]

I noticed that in this project Im working on Labview was responding slow when making wires and connections and such.  Checking with task manager shows

60% load on the cpu. When I close the VI and open another there's no noticeable load (like 6%). What is going on? It is in edit mode so its not running.

Edit: When its running its showing normal CPU usage like a few percent. See attached figure.

[_Faust]

Only loading a standard waveform chart gives me 60% cpu usage, is this normal? Its a dual core 2.4 ghz.

I have attached just the chart to see if anyone else has the same

[smercurio_fc]

No, it's not normal. But then you don't seem to have a standard chart on the front panel. It appears you made some modifications, and it seems that one of these modifications is triggering this behavior. Can you repeat your steps and see which one starts to cause the aberrant CPU usage?

[altenbach]

I agree. It looks like you uncovered a bug somewhere. THis is something NI should investigate. I have made a note in the bug thread.

(Also, what's up with that tight front panel grid?)

[_Faust]

Well, I just tweak the chart to whatever the customer wants it to be, so its hard to remember all the things I did exactly. but I think -if I recall correctly- I used a NI Themed waveform chart as a start.

Its available somewhere online in the developer zone as a control package. I will check if all those have that behaviour.

Last, I have used this very same chart in another VI where it also shows the same CPU usage.

[_Faust]

oh and about the tight front panel grid: I dont like the snap-on to grid when its spacy. I have a designer working out all user interfaces so I always need to

position controls pretty accurate. As a matter of fact I havent paid attention to this since the day I changed itto see whether I would like it or not.

[JackDunaway · Accepted solution]

I knew immediately what the problem was, because this asschapper has gotten me dozens of times. You imported a custom graphic and then tried to paint it transparent. Use the recolor tool to make your CPU go back down to 0%.

Picture below shows I can recreate the issue

Shows the part that's going haywire:

After recoloring, I have revealed your initial custom graphic and fixed the problem. In the future, to create a custom part of a control or indicator, import a flat decoration that has been colored Transparent/Transparent.

Thanks, altenbach, for the heads up in the Bugs Thread. I would love to see this bug get fixed, because it's particularly nasty when it manifests itself only in the built EXE but not the dev environment.

[JackDunaway]

A theory for this bug: the "parts" of the control are in an infinite loop invalidating each other, somehow triggered by a fully transparent part. You can sometimes see the ant trail flickering madly on a selected object in the dev environment.

[altenbach]

---

@JackDunaway wrote:

A theory for this bug: ....

---

Is there a CAR #?

[JackDunaway]

---

@altenbach wrote:

---

@JackDunaway wrote:

A theory for this bug: ....

---

Is there a CAR #?

---

I've never reported the bug. The theory is just wild speculation based on information learned while tracking down the source of the bug a while back (in the LV 8.6.1 era).