These two would help to sort out VIs when you want to make llb plugins, to determine who goes where.
I'd like to right click on an item in the project explorer, and have two more options "Open private callees" and "Open public callees.
By "private callees" I mean: the callees that the selected VI is the only one to call in the whole project.
By "public callees" I mean: the callees of the selected VI that are called by at least one other VI in the project.
(I mean directly called and not dynamically of course, the developper would have of way to distinguish his VIs that are called dynymically).
Again, I've done it for personal purposes, here's the snippet in 8.6 for those who might like it.
Right click on an item in the project explorer, you have "Find Callers" and "Find SubVIs", select one of these, you get small pop-up window with a list, double click on an item of this list, the item comes to front and the list disappears ... I always get mad at that behaviour!
I'd like an option to OPEN all Callers of the VI, I mean of course all the callers that are part of the project in which your are.
I made a utility VI doing that in LV 8.6, if anyone likes it here's the snippet :
Pretty self explanatory.
Place an image on the front panel.
Use the "Get Color" Tool from the tools palette on a color on the image.
The foreground color should ideally be the color you clicked on, however it's always Black with a White Background.
I'd think that getting colors from an image should work like getting colors from anything else on the front panel. It would be pretty nice to be able to match the FP elements with an image thats on it for better GUI design.
It should be nice to add custom message to the error cluster.
When you use the codified error codes, you cannot use dynamic error messages like : "File XXXX not found !"
So it would be easier to build more "user friendly error messages" ...
An additional Timestamp would also be usefull !
Something like this ....
To bypass this, i personnaly concatenate my custom error message to the error source.
It's not terrible ... but i have no other choice !
It should be nice to be able to create a "typedef enum" for the pages of a tabcontrol ...
So the modification of a tabPage label could be automaticaly propagated to constants ..
The problem is ... When you modify the pages labels, and if you use the constant value associated with the pages ...
The associated wires are then brocken ... They are not automatically modified
When you only want to modify the Label of a tabPage (For example to correct a mistake), the Vi will no more work !
An other idea would be to add a kind of "Caption" to the tabPages, in order to disociate the 'Display name' and the Variable name ...
Here a short example ...
Other Idea : (From the well known Roms)
It should be nice to create the TabPages of a TabControl automaticaty from a typedef enum, and keep the link between the two items.
=> Modification of the TabPages modifies the typedef enum
=> Modification of the typedef Enum, modifies the TabControl content
It should be nice to modify the "Unflatten from XML" in order to be more tolerant with data evolutions.
For example :
I used the flatten/unflatten to/from XML to store my applications configuration. It's rapid ... and it works fine ...
But during the software life, you often have to modify the data structures ... and then you'll get problems !
The old XML string is no more compatible with the new data structure ! ... and old config files are no more usable !
( And sometimes only for a single new field !!! )
This could generates problem when you deploy a new version of your program ... and the old config files can no more be reused !
So it would be nice to have a more 'Tolerant' XML parser :
For the moment the Xml unflatten generates an error when the type definition is not compatible ... and nothing is done.
The new behaviour could be to load "Compatible datas" (by name and dataType), initialize new fields, ignore deleted fields,
and a warning error cluster could be generated to inform that the XML parsing could be done ... but XML schema is not completly compatible.
Over the years the wiring routines have been improving a lot, here is a next step that would make wiring even easier.
I call that "Bad wire gets cleared automatically when it can", it would take me 50 lines to explain, so here are to screen shots to explain what i have in mind :
It would be nice to add a new control/indicator in Labview, which could view and edit the content of a cluster ( recursivly ) in a tree view.
The viewer could looks like the Microsoft Dotnet Property grid.
It should be nice to add "Docking" and "Anchoring" features in Labview.
This could help creating "autosizable", professional applications.
For the moment, splitters and "control fitting" is a little poor, comparing to DotNet, Java ...
In the 'Source File Settings' category of the 'Build Specifications' dialog one has the option of customizing the destinations of the elements of the build. One very handy feature here is that it is possible to set the destination for all elements contained in a folder (virtual or auto-populating).
In the project tree Libraries, Classes and Xcontrols act like folders in that they have a parent item containing child items. Unfortunately the 'Set destination for all contained items' feature is not implemented for these parent items.
A work-around is to put the class/library/xcontrol in a folder and then set the destination for the folder but that makes the project look very messy.
Here are some pictures:
In most of the cases, front panel is not use for a subVI, but it always disturbs me be opening too many windows. So, there should be a new kind of VI that only have a block diagram. Terminals could be designated on the block diagram.
We all use clusters and arrays of clusters to represent complex data. With LabVIEW, it is practical to build a cluster to represent the data in memory and shape it to display it on the front panel. Using the same object (control or indicator) to display the data on a graphical user interface and to store the data in memory avoids overloading the memory and simplifies the code.
But most of the time, all the data don't need to be shown on the front panel! Some elements need to be hidden. If we use a probe to check the content of such a data structure for debugging purpose, LabVIEW just shows the control as it is supposed to be displayed on the FP. The hidden elements are not visible!
Here is an example of a probe put on one of my data structure (array of clusters) :
And here is the equivalent representation in a tree view. On the first column, the labels. On the second column, the values.
What is your prefered representation?
PS : Such a tree view representation can "easily" be obtained from a control reference or from an XML string (with the Flatten to XML VI). Nevertheless, the Flatten to XML VI returns an error when it encounters strings with accentuation.
I have noticed that Property Nodes for certain numerics do not properly store Range Properties as the native datatype of the control, but rather stores them as DBLs. I have attached the screenshot to illustrate my point:
Notice the first Numeric's datatype is a DBL, and therefore you see no coercion dots for the Range Properties or the Value Property. The bottom two examples show I32 numerics, which have the proper datatype for the Value Property, but have the wrong DBL datatype for the Range Properties.
I propose that the Range Properties should reflect the datatype of the Numeric, just as the Value Property does!
(This may affect other Property/Invoke Nodes besides Range... please list any other datatype inconsistencies you may find in the comments.)
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).
More function for tdms file.
The tdms files are a very good way to record data on disk, but some usefull function aren't present.
- you don't can delete a channel or a group or a value or a property
Exemple : You add the measurment in the group 'raw data', channel 'volt'.
In the group 'calculate data', you add the channel 'filtered volt'
You change the filetring parameters. You wan't to replace the channel 'filtered volt' with the new data, but you don't can easy replace the old data (channel 'filtered volt')
You must copy all data in a new file without the channel 'filtered volt' befor you can add the new calculation.
- you have only 2 hierarchy (group and channel). More should better ?
exemple : 'acquisition\device name\channel name\acquisition number'
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.
It would be nice have the drag-and-drop behavior in some box type decorations that will place a control inside it, just like Clusters. Can have also the same options to organize (AutoSizing: None, Size to Fit, Arrange Horizontally, Arrange Vertically). Nowadays, if we want to to have some graphically grouped controls, basically we have to:
I the proposed way:
If a control needs to be added to the group, nowadays we have to:
In the proposed way it will need only one step:
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)