Updating Table Oddness

[Ed Dickens]

Here's one that may be a bug, or may be just something to watch out for.

When updating properties of a table, it takes longer to process those update depending on what part of the table is showing on the front panel.

Looking at the attached example, it just populates a table with 1023 rows and 25 columns, sets the row headers, then changes the background color of one of the columns. Setting either the foreground or background color causes the problem. Setting a different property does (like Cell Size) not seem to cause any problems.

Before setting the color, I turn on "Defer Panel Updates", then set the color and turn off the deferring. Doing this alone cause the color change to take about 7 seconds on my machine if you have the end of the table displayed (scroll all the down). Also note that if you are displaying the middle of the table it takes about 3.5 seconds to update. It seems somewhat proportional to the displayed position. It also has the same effect if you scroll horizontally.

If you have the start of the table displayed, it takes about 300ms.

If in addition to deferring the panel updates, I set the Index value to 0,0 it takes the 300ms.

It has this same problem all the way back to version 6.

The zip file has 4 versions of the file for LabVIEW 7.1, 7, 6.1 and 6.

Ed

Download File:post-47-1114100834.zip

[victor]

Hello all.

I think it is really a bug with Labview.

I ran across a similar problem today, when I was trying to build some XML strings from data in a "table" (string array). I noticed that all data was not updated, causing the vi to generate strings with "old" data.

I wrote a smaller .vi where the problem is "isolated" (the only table function I used was "set cell"). The vi populates the table with current time, then the table is read and the data is displayed in another table.

The odd fact is that, everytime the vi runs, the second table displays data from the PREVIOUS run!

Please, could someone help me to get around this problem? How can I programatically "force" the table to get updated?

Thank you!

best regards,

Victor Rocha

:headbang:

Download File:post-2454-1119471444.vi

[victor]

Hello again.

I solved my particular problem by not using "set cell" anymore. Now I used "replace array subset" like in Ed

[Barrie]

Here's one that may be a bug, or may be just something to watch out for.

When updating properties of a table, it takes longer to process those update depending on what part of the table is showing on the front panel.

Looking at the attached example, it just populates a table with 1023 rows and 25 columns, sets the row headers, then changes the background color of one of the columns. Setting either the foreground or background color causes the problem. Setting a different property does (like Cell Size) not seem to cause any problems.

Before setting the color, I turn on "Defer Panel Updates", then set the color and turn off the deferring. Doing this alone cause the color change to take about 7 seconds on my machine if you have the end of the table displayed (scroll all the down). Also note that if you are displaying the middle of the table it takes about 3.5 seconds to update. It seems somewhat proportional to the displayed position. It also has the same effect if you scroll horizontally.

If you have the start of the table displayed, it takes about 300ms.

If in addition to deferring the panel updates, I set the Index value to 0,0 it takes the 300ms.

It has this same problem all the way back to version 6.

The zip file has 4 versions of the file for LabVIEW 7.1, 7, 6.1 and 6.

Ed

4588[/snapback]

This is more of a comment than an insightful reply but if my memory serves me, cell based operation can be sped up significantly by the following:

Set the visible attribute of the table false

Make all your changes

Set the visible attribute of the table true

This may not apply to later versions, but I do remember that this particular object is very graphically dependent. I don't think it is a bug per se, but the code is probably in need of optimization.

Sigh.... Poor NI, so much code, so little time.

Cheers to all,

Barrie