LabVIEW Idea Exchange

Populating the Tree Control with items takes very long time.  I suggest improving the performance of a tree control.  Many other applications have tree controls that are populated in a small amount of time, so it should be possible with LabVIEW.

I know of three ways to populate a tree control.  The first is to individually add items using the Add Item invoke method.  This method takes a very long time.  Adding 15,000 entries took over 180 seconds.

The second way is to use the"Add Multiple Items to End" invoke method.  This took over 20 seconds for 15,000 entries.

The third way is to programatically respond to the user expanding an item in the tree and populating only as necessary.  I assume that this is fast, but it seems like a lot of work to do every time a tree control is used that could have a lot of items. Maybe LabVIEW could improve performance by using the third approach internally for the programmer. 

Currently I am hesitant to use a tree control because of performance.  LabVIEW is a great product, and making the tree control perform better would improve LabVIEW even more.

It would be nice if XControls could maintain arbitrary state information akin to display state but was volatile and so not preserved when the XControl was saved and (importantly) did not set the VI modified flag when it was changed.

An XControl's display state is the natural place to store all state information about the XControl that you might want to access via property or method nodes as well as via user activity on the facade.  However, anytime the State Changed ? flag is set in the facade, then container vi is marked as having unsaved changes. This is obviously sensible if the state change is meant to persist - e.g.. control resize, but not if the state change is volatile and can bee discarded after each run.

There are various alternative methods that can currently be employed, but they are not satisfactory:

1) Additional shift registers on the facade - are not available within property or methods

2) Storing volatile state data in LV2 style globals - unfortunately the same global is shared between instances of the XControl. This is still the best solution as the Container refnum can be used to generate a per-instance unique identifier to enable the global to manage the state data for all instances of the XControl.

3) Storing volatile state data in a 1 element queue. There are two problems - firstly some daemon process needs to be able to keep the queue reference alive but this adds complexity in making sure the dameon process shuts down cleanly. Secondly, there is still a problem of ensuring separate data storage between instances of the XControl.

4) Storing volatile state with the data. This works where the data type supports attributes I.e.. variants and waveforms but not for the general case.

5) Storing volatile data in a tag of the container refnum. This requires scripting and private methods and only works in the development environment.

A better solution would be an additional ability type def that is provided for volatile state, presented as a control/indicator pair for properties and methods and prepare to save, wired through on a shift register for the facade and presented as an indicator to init and as a control to uninit.

In LabVIEW 2009, the programmatic API for shared variables and I/O variables was introduced. This allows you to reference a variable by name, rather than dropping a static node on the diagram.

Some of the benefits are: iterating over many variables with looping structures, creating modular code, and dynamically accessing variables based on names in a config file for example. 

Programmatic access to single-process shared variables would also be useful.

(Single-process variables are effectively global variables (not network published), but use the same static node as the shared variable and are contained in project libraries.) 

I have 2 suggestions for the highlight feature.

1. A slide bar or some other way to set the speed that the highlight runs.

1.  A way to only highlight a section of code but run the rest full speed.

Maybe it could it be done by selecting an area, as done with the diagram disable?

Or with break points. Highlight between points?

Most of the time when highlighting, you don’t need the entire VI to highlight just one small section or frame. So, you put in a break point before and after the section you want. When the code pauses, you turn highlight on. When it pauses again, you turn it off. On large loop iterations, this is very time consuming.

An example would be for nested loops. If there are 3 nested loops and you would like to highlight one small area of code in the second loop. You have to: continually wait for the inner loop in highlight, or pause-highlight-unpause every iteration.

I would like to propose the use of a stacked parallel execution structure.  Especially in FPGA applications, this will solve the problem of diagrams running off the screen.  All execution pages will run simultaneously as if independent while loops were scattered across the BD.  This idea potentially leads into a 3 dimensional visuallization of coding LabVIEW. Note: In the image, the pages are offset but should look similar to a stacked sequence structure.