12-01-2008 02:28 PM - edited 12-01-2008 02:30 PM
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?
12-01-2008 02:49 PM - edited 12-01-2008 02:49 PM
NOTE: Something ate the attachments/inline pictures above. Please see the LAVA thread for the images.
12-01-2008 03:05 PM
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:
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 PMMessage Edited by Ben on 12-01-2008 04:05 PM (eastern US)
Ben
12-02-2008 01:59 AM
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
12-02-2008 05:40 AM
12-06-2008 10:25 AM
12-06-2008 10:32 AM - edited 12-06-2008 10:35 AM
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
12-11-2008 06:10 AM