12-28-2010 03:31 AM
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
12-28-2010 06:23 AM
The Attached VI (in LV 8.6) shows how to restrict the scrolling.
12-28-2010 07:53 AM
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
12-28-2010 12:17 PM
@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.
12-28-2010 12:31 PM
@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
12-28-2010 01:07 PM
@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)
12-28-2010 07:09 PM
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