LabVIEW Idea Exchange

I'd like to have the ability to save a LabVIEW search (Find), with some commonly used parameters.  It might be nice to choose between saving the search globally, or in a project.

Also, I'd like to be able to recall recent search results.  Often, my searches are hierarchical: I search for some high-level stuff and then do a more specific search.   I don't want to lose my high-level search results, when I drill down and do a more low-level search (for example, the low-level search might be fruitless, so I need to go continue on with the rest of the results from my high-level search).

Having a complete API for zip file

Currently it has :
- New zip file
- Add a file to zip file
- Close zip file and add a comment
- unzip the zip file to a folder

This API is not quite complete.

Example of use of ZIP files: In a data streaming application, you want to make an archive of recordings files. The data files average 500 MB Once compressed, they do more substantive than 50MB. You create an interface to assist the user in steps of compression. Once compressed, you want to propose an interface for retrieving compressed recordings.

The ideal is to list the files and clarify some information, such as track number, recording time and a few other indicators related to data.

But to do that, we 'could' use two ways:
- The properties of the zip file.
- An additional file that would read that to see them.

Several problems arise:
- It is not possible to read the commentary added with the close function.
- It is not possible to edit the commentary added with the close function.
- It is not possible to decompress a single file.
In the example, if we unpack all files to read properties, it'll take time and a lot of CPU resources.

It would require full management functions:
- New file
- Close file
- Add a comment
- Read the comment
- Erase the comment
- Add a file
- Delete a file
- List all file (with or without a mask)
- Uncompress a zipped file to disk
- Uncompress a zipped file to memory

- compress and uncompress a string in memory (usefull to optimise the network data flow)

In the ideal case, a zip file should be considered a folder. So we have all classical file functionality to manage it.

Hi,

Another behavior that I find annoying isthe way LabVIEW manage the tabbing order with cluster.

Imagine a front panel with clusters (I thinkthat this is not unusual and that you will have no pain to imagine this). If acontrol embedded in a cluster has the key focus, the TAB key will only give thefocus to controls of this cluster. It is impossible to navigate outside thecluster!

In the following front panel I wouldexpect the following sequence when tabbing: Cluster_1.String_1 -> Cluster_1.String_2-> Cluster_1.String_3 -> Cluster_2.String_1 -> Cluster_2.String_2-> Cluster_2.String_3 -> Cluster_1.String_1 -> …

(According to  the cluster tabbing order)

Hi,

Key navigation is essential when a PC isused in an industrial environment that limits the use of the mouse (rackedsystems on production lines, temporary connection with a laptop to an RT target, etc.).

One lack is the impossibility to associatea simple shortcut key to a Boolean control (CTRL+S for example).

Of course we can catch the key down event in a newcase of an event structure. But, we then have two cases forone action (one for the shortcut key and one for the Boolean value changed),what is not practical.

In addition, since LV 8.0 (I guess!) it is notpossible to underline one letter of a Boolean text to stress the shortcut keyassociated with the control.

From my point of view, this is an essential fonctionnality of any development system.

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.