LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

highlight table cell speed

if selected cells is much greater than the rest, this may be a solution. but how you can restrict the scrolling, in labview,  user even cannot capture the mouse scroll key event, unless program keep checking the "index value" and reset "index value".

 

what is the method you use to restrict the scrolling, when user use the mouse scroll key to scroll table.

 

and if selected cells is almost same as the rest, 1000 cells:1000 cells, any solution?

 

thanks

0 Kudos
Message 11 of 17
(1,162 Views)

The Attached VI (in LV 8.6) shows how to restrict the scrolling.

0 Kudos
Message 12 of 17
(1,149 Views)

In one version of LV the defer did not work corectly.

 

Another thing that can speed up the BG color change (short of resorting to limiting the size of the data in the table, whcih will work but requires a lot of code to support it) is to

 

Defer FO pudates

 

Hide table

 

Update table

 

Show table

 

Undefer updates

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 13 of 17
(1,140 Views)

 


@Ben wrote:

In one version of LV the defer did not work correctly.


 

Yes, this seems to be the case here. 😞

 

I've been doing some tests and there are a few more weird observations. For example, the time to update 500 rows x 3 columns is about 2000ms most of the time. But sometimes after some editing operations it is consistently ~850ms and sometimes consistently ~5000+ms.

 

If we assume you want to highlite entire columns, it is sufficient to iterate over the columns with the row set to -2.

 

Attached are a few attempts to play (also note that one property node is enough to set the position and color. No need for two.)

 

If your table is really big, you might want to only color the cells currently visible and re-color the visible area whenever the scroll positions changes. This requires quite a bit more code, however.

 

 

Message 14 of 17
(1,131 Views)

@altenbach wrote:

 


@Ben wrote:

In one version of LV the defer did not work correctly.


 

Yes, this seems to be the case here. 😞

 

I've been doing some tests and there are a few more weird observations. For example, the time to update 500 rows x 3 columns is about 2000ms most of the time. But sometimes after some editing operations it is consistently ~850ms and sometimes consistently ~5000+ms.

 

If we assume you want to highlite entire columns, it is sufficient to iterate over the columns with the row set to -2.

 

Attached are a few attempts to play (also note that one property node is enough to set the position and color. No need for two.)

 

If your table is really big, you might want to only color the cells currently visible and re-color the visible area whenever the scroll positions changes. This requires quite a bit more code, however.

 

 


One of my co-workers had a project that required populating a table from file within a finite amount of time.

 

In the end he ended up writting the guts of a XControl that would "make it look" like all of the data was in a table but in reality he used "smoke and mirrors" to look like a table.

 

I tell that story to let you know that when it comes to large data sets, the table can be quite slow so don't think it is due to poor coding.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 15 of 17
(1,127 Views)

 


@altenbach wrote:

For example, the time to update 500 rows x 3 columns is about 2000ms most of the time. But sometimes after some editing operations it is consistently ~850ms and sometimes consistently ~5000+ms.


 

The time seems to depend on the vertical scroll position of the table. If we scroll all the way to the bottom of the table and again color 500 rows x 3 columns, the time it takes is much (much!!!) longer.

 

(I don't know what sometimes causes the faster 850ms times after some editing operations)

0 Kudos
Message 16 of 17
(1,119 Views)

may be we can combine "highlight entire column" method and "cell by cell" method.

 

whenever table "index value" changes, make a decision which method to use

 

when current visible cells are all under selection, then use "highlight entire column" method, if current visible cells are partially under selection, then use "cell by cell" method. 

 

but the problem is how to detect the table "index value" change, using polling or event driven, i cannot find any events related to "index value"?

 

thanks

0 Kudos
Message 17 of 17
(1,098 Views)