"Window runs transparently" bug

[vix]

I found a strange behavior of "Window runs transparently" property:

• the attached vi has this property enabled, and the value set to 100% (completely transparent) - verify this in the property window
• run the example, that changes the transparency to 0% (completely opaque)
• press the stop button
• re-open the property window and verify that transparency value is now set to 0%. Why?
• In this situation, if you save the vi, you loose the 100% setting....

[smercurio_fc]

Your VI uses a subVI which we don't have. It appears to be the one doing all the work, so it's possible the bug (if there is one) is in that VI.

[jojp]

LabVIEW saves default values for all controls. It does by default not safe the last setting.

[vix]

I removed the vi from LAVA.

The problem is not there

[smercurio_fc]

OK, I see what you are saying now. I would agree that this is undesired behavior. Not sure if it's a bug, though. Definitely undesired, though.

---

@jojp wrote:

LabVIEW saves default values for all controls. It does by default not safe the last setting.

---

That's not the issue here. The issue is that if you change the transparency programmatically it updates the VI's properties and if you save the VI it gets saved with the last programmed value, not the value that you set by typing a value into the "Window runs transparently" box.

[smercurio_fc]

Of course, now that I think about it a bit more, I could make an argument that it's a bug. It's changing a property, but not setting the "dirty bit" that the VI has changed, which does happen if you manually changed the transparency setting through the VI properties. The issue here is that if you run the VI the property gets changed, but the dirty flag is not set. You go an make some other changes to the code, and save the VI, and the VI is saved with the new transparency setting (which is not what was expected or desired).

[vix]

---

@smercurio_fc wrote:

Of course, now that I think about it a bit more, I could make an argument that it's a bug. It's changing a property, but not setting the "dirty bit" that the VI has changed, which does happen if you manually changed the transparency setting through the VI properties. The issue here is that if you run the VI the property gets changed, but the dirty flag is not set. You go an make some other changes to the code, and save the VI, and the VI is saved with the new transparency setting (which is not what was expected or desired).

---

You described perfectly the situation. This is exactly what I experienced, and so I decided to post on this forum.

[X.]

Since apparently nobody at NI followed up on that (the VI is still doing the same in LV 2013) and I have a (somewhat) related remark to utter, I'll try to catch two birds with one stone.

Here is what I noticed regarding transparency:

If you set a non default transparency value such as say, 50% and hope to try and see how that works out at run time, i.e. try to Ctrl-M the thing, nothing will happen.

In other words, forget about testing transparency effects without running your full blown VI.

It does not work.

Users: 2, NI: 0

[rolfk]

---

@X. wrote:

Since apparently nobody at NI followed up on that (the VI is still doing the same in LV 2013) and I have a (somewhat) related remark to utter, I'll try to catch two birds with one stone.

Here is what I noticed regarding transparency:

If you set a non default transparency value such as say, 50% and hope to try and see how that works out at run time, i.e. try to Ctrl-M the thing, nothing will happen.

In other words, forget about testing transparency effects without running your full blown VI.

It does not work.

Users: 2, NI: 0

---

This is intended behaviour and desirable. Try to set transparency to 100% with a simple run endless loop and start your VI. You can even add a Stop button to your front panel!! 

Then try to end it without force closing LabVIEW!

Yes there are ways to stop the VI but they go far beyond what an average LabVIEW user would know to handle.

Imagine this to happen to a VI just because you changed the transparency setting and happen to put it in run mode. LabVIEW can't prevent you from shooting in your own foot if you absolutely insist on it, but goes to some lengths to try to minimize the possibilities for that.

[X.]

What are you talking about? Ctrl-M is intended to "preview" how the panel will look like at run time.

As far as transparency is concerned, it would seem to be very useful to know whether 30% is fine or maybe 50% is needed.

Currently, setting these values for the window's property and tring Ctrl-M does nothing.

Since Ctril-M is reverted by another Ctrl-M, it can hardly be called a loaded gun.

As far as the other behavior, I was just stating that it is still here and nobody from NI has bothered explaning the rationale of it.