By Mike King
Hi LAVAers. I thought I'd post this up to grab some more eyes and ideas, and maybe contributors if there is interest. I've started development of an open source datagridview project using .NET in LabVIEW to finally have a well implemented datagrid for use with LabVIEW UIs, data types and event integration. I have this all working in a sample project and would love more ideas, feedback and and help if anyone wants to contribute.
The project is hosted on github, https://github.com/unipsycho/LabVIEWdotNetDataGrid
I started a discussion for it in the LabVIEW NI community site when I started but its a LOT more presentable now, so extending this to LAVA. The original discussion is here:
The main premise of the project is to have extended data types, extended features with a event driven datagrid for LabVIEW using .NET.
Please let me know what you think or if any questions or ideas to add to this.
By Colin Zhang
Which style TABLE control can support the direct input and selective input as same? or how to achieve this function?
I have tried the Modern/Classic/System style Table, but can not find a way to achieve this goal.
After getting pretty deep into an experimental control paradigm with a Table Control as the user interface, I've run into the very frustrating problem of slow formatting updates (cell background and text color). Even when deferring panel updates, formatting a 50 row by 200 column table based on each cell's string takes seconds. The UI table assists the user in generating a 2d string array, which is subsequently sent to a set of hardware objects to control a Bose-Einstein condensate experiment.
From reading other posts on this forum and the NI forums, I've compiled the following suggestions:
defer panel updates (helped a lot, but still too slow) set subVIs containing table Property Nodes to execute in 'user interface' thread (I've tried this but would love to know more about optimizing it. Should the subVI attempt to only contain Property Nodes with logic outside in a different thread?) maintain a "display" table which is a subset visible to the user (seems pretty complicated and may only give gains of factor of 2 or 3 since I want the Table to fill the user's monitor) obviously, take all steps to format by column, row, all (not possible for about half my columns whose coloring depends on each cell's value)
Is the above list exhaustive? Can anyone suggest something I haven't listed?
I'd also appreciate more information about UI thread control. My naive understanding is that table coloring is so slow because to color cell-by-cell the process must switch up to the UI thread and back down. And setting a subVI property to the UI thread saves some of this thread-switching time?
Barring any other insights, it seems like we've been burned by trying to use a table control in an unintended way and LabVIEW simply can't do it fast enough. Do XControls suffer from the same thread-switching problems for front-panel appearance updates via Property Nodes? Otherwise, I'll work on rewriting the UI in another language and simply feed the 2d string array to the rest of my LabVIEW code.
I ran into this error while developing the project I'm currently working on. I've isolated the cause of the error and I'm able to demonstrate it in a simple VI.
Basically, if I make a new selection on an enum or ring, while using the "set cell value" method on a table, error 1604 is generated.
I want to understand why this is happening and also be able to fix it.
test error 1604.vi