LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Transparent Picture Control Quirks?

(cross-posted to LAVA)

 

Can anyone explain this?

 

A Picture Control that has been painted transparent has a different Erase First behavior in the context menu.


Regular picture control, dropped right off the palettes:

 

Note that the Erase First item is enabled, and checked by default.

But, if we use the paintbrush to paint the interior of the Picture Control transparent and then bring up the context menu again:

 

Note that now Erase First is checked and disabled so it cannot be unchecked.

But there's more.  If you try to set the Erase First behavior programmatically, LabVIEW doesn't generate an error and seems to accept the setting, but the change isn't reflected in the context menu:


It also appears that, regardless of the behavior shown, a Picture Control that's been painted transparent ignores all programmatic Erase First settings and behaves as though it's set to Always Erase.  This, in turn, means that if you set a Picture Control's background to transparent, it will always tend to flicker as you draw more stuff to it, unless you take special precautions (like deferring panel updates).

Why does a transparent-background Picture Control behave differently from a Picture Control with an opaque background?

Message Edited by Justin J. Goeres on 12-01-2008 02:30 PM
0 Kudos
Message 1 of 8
(4,666 Views)

NOTE: Something ate the attachments/inline pictures above.  Please see the LAVA thread for the images.

Message Edited by Justin J. Goeres on 12-01-2008 02:49 PM
0 Kudos
Message 2 of 8
(4,656 Views)

Since;

1) Justin is used to the "Dark-side" and

2)all picture related question interest me

3) And NI does not answer Q's on LAVA I will help out a bit. The following is what I think Justin wanted us to see,


Justin J. Goeres wrote:

(cross-posted to LAVA)

 

Can anyone explain this?

 

A Picture Control that has been painted transparent has a different Erase First behavior in the context menu.


Regular picture control, dropped right off the palettes:

 

 

 

Note that the Erase First item is enabled, and checked by default.

But, if we use the paintbrush to paint the interior of the Picture Control transparent and then bring up the context menu again:

 

 

 

Note that now Erase First is checked and disabled so it cannot be unchecked.

But there's more.  If you try to set the Erase First behavior programmatically, LabVIEW doesn't generate an error and seems to accept the setting, but the change isn't reflected in the context menu:

 

 


It also appears that, regardless of the behavior shown, a Picture Control that's been painted transparent ignores all programmatic Erase First settings and behaves as though it's set to Always Erase.  This, in turn, means that if you set a Picture Control's background to transparent, it will always tend to flicker as you draw more stuff to it, unless you take special precautions (like deferring panel updates).

Why does a transparent-background Picture Control behave differently from a Picture Control with an opaque background?

Message Edited by Justin J. Goeres on 12-01-2008 02:30 PM
Message Edited by Ben on 12-01-2008 04:05 PM (eastern US)

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 3 of 8
(4,646 Views)

I ran into this exact same issue when working on a project a while back.  I don't know the cause, but CAR #35724 is filed on the behavior.

 

-D

0 Kudos
Message 4 of 8
(4,616 Views)
I think this can be explained.

As often, NI thought they had to thing for us.

Why would anybody want to not clean a transparent picture? No one answers.
So we'll disable it...

Regards,

Wiebe.


0 Kudos
Message 5 of 8
(4,601 Views)
 
Rolf Kalbermatter
My Blog
0 Kudos
Message 6 of 8
(4,544 Views)

Wiebe@CARYA wrote:
I think this can be explained.

As often, NI thought they had to think for us.

Why would anybody want to not clean a transparent picture? No one answers.

So we'll disable it...

 

Almost! There is no way to allow real transparency without letting the parent redraw itself (or cache whatever background is current) and then draw itself over that. Remember the background can change at anytime for whatever reasons too. Most probably overlapping objects are informed of redraws of underlaying parts somehow so the control can cache a snapshot of the background AND redraw itself over it. But there is no way of maintaining transparency without a complete redraw of the background area AND the picture control itself whenever the contents of the picture control remains.

 

I guess you could argue that one might want to allow an addition of new contents without redrawing even when set to transparent but this was obviously thought useless and I'm sure there are more caveats to the issue that make this indeed very difficult to implement correctly.

 

Rolf Kalbermatter

Message Edited by rolfk on 12-06-2008 05:35 PM
Rolf Kalbermatter
My Blog
Message 7 of 8
(4,543 Views)
Rolf,

That seems like a valid explanation...

I tried to blend a transparant png file once with a VI's background, and it
wasn't very easy. It would have been easy, but getting the background of a
pane was very buggy in 8.2.1. Haven't tested it in 8.5. This won't work with
backgrounds that have images through...

Regards,

Wiebe.


0 Kudos
Message 8 of 8
(4,466 Views)