LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Using Transparent Table Control Background -- Avoiding data persistence/Force table redraw QUICKLY!

I am developing an application where I want to see an image behind a table, thus requiring the table to be transparent. This is a great idea; however, it is long been known that LabVIEW table controls need to have a colored background so that they will redraw correctly. This behavior dates back to 2001 as far as I can tell in the following posts.

 

http://forums.ni.com/t5/LabVIEW/Transparence-Table-bug/m-p/452040/highlight/true#M219592

http://forums.ni.com/t5/LabVIEW/Bug-in-LabVIEW-Table-Display/m-p/894205/highlight/true#M403677

http://forums.ni.com/t5/LabVIEW/Old-table-values-are-persisting-under-the-new-values/m-p/479166/high...

http://forums.ni.com/t5/LabVIEW/Flickering-Table/m-p/22332/highlight/true#M15320

 

There has been numerous work arounds, some ugly, some not so ugly. While reading about one such work around in CVI that mentioned disabling screen updates, hiding the table, updating the table, making the table visible again, then resuming screen updates, I had a thought to apply this new found knowledge which was meant to allow for faster table updates. I started experimenting with stringing property nodes out to hide and un-hide the table as it was being updated. Then stumbled on a very simple fix, write the table data to the value property node. This seems to force the table to redraw and is quite fast for smaller tables. I have not tested this in every situation, but it does work for me.

 

Below are the screen shots and snippet of the code:

 

First, the "broken table" code:

 

Transparent Table Broken.png

 

Next, the "fix":

 

Transparent Table Fixed.png

 

Code snippet:

 

TransparentTable Fix.png

 

Well, the snippet isn't quite what I coded, but you  get the picture.

 

I normally have controls outside of the process loop as demonstarted above because I do a lot of modifications by reference in separate threads or sub-vi's so I am suprized that I didn't code in this way for this particular control in the first place.

 

Anyway, I hope this is useful to others who want to use a transparent table without having to resort to putting transparent decorations, cleverly copying the front panel background color, or other strange LV black magic techinques to get their data to update correctly.

 

Drew

 

Manufacturing Automation Systems, LLC

Sr. Systems Engineer

CLD

Message 1 of 4
(3,080 Views)

Interesting behavior. Same thing still happens in LabVIEW 2011. Although I found that Greg McKaskle's "trick" of placing a hollow decoration over the table also works (i.e., you can use the terminal and just place a hollow decoration over the table).

Message 2 of 4
(3,060 Views)

WHY is this still an issue in 2016?  Writing to the property node (NOT local variable) does work.  You would think these kinds of bugs would be worked out by now......

0 Kudos
Message 3 of 4
(2,613 Views)

It may have more to do with the underlying MFC code than anything actually in LV. I have never investigated this further than what I did previously.

0 Kudos
Message 4 of 4
(2,603 Views)