Search the Community

So, I wanted to get an opinion here? I'm Pulling new values in from a device, and have UI elements change color depending on their value. This is of course done through property nodes. My question is what is better: A. Updating UI element only on value change (checking for value changes) B. Updating all UI elements all at once within a Defer front panel updates segment? ( and not checking for value changes) Thats all.

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.