There are already "Simple Numerics" and "Simple Strings" on the classics menu. I'd like to see "simple clusters" and "simple arrays" added.
Or else give us the ability to customize the Cluster and Array controls to reduce the wall size of the bounding box down to a pixel width.
I want to find string constants containing a particular word, say "LabVIEW", in my LabVIEW project. At moment, I can use "Find and Replace" to search for String Constant, but this returns all the string constants I used in my LabVIEW project. There are just too many of them. It would be really nice if there is a filter option where I can search for a particular subset of the string constant, for example, a particular field where I can enter <*LabVIEW*> to serach for string constants containing teh word "LabVIEW". The same applies to searching for path constant and numeric constant.
For the moment the INI file is managed as global feature (Link in the executable : Link to Labview.ini by default )
I think the INI keys are part of the project.
So it would be more "User Friendly" to be able to edit them as "Project properties". (Like conditional disable symbols)
Associated directly the INI keys to the project will avoid to lost important part of your application.
For example the key "useLocaleDecimalPt" is usefull when you want to force the decimal point to ".".
This is usefull when you use "Instrument drivers" which are decimal point dependant ... but don't alert when the active decimal point is ','.
I think that ini keys are part of the source code. So theire place is in the project, as project properties ... (Not globaly managed in the Labview directory)
I think that adding INI keys to the project will limit the problem of "source lost" when you many personns works on the same project ...
Or when you had to modify an old project on a new installed PC.
For the moment, I create my own local INI File in my project ... but it is not user friendly, it's manual !
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
I am not very experienced in LabVIEW but i faced a problem while giving a DBL value (representation of numeric) to a case structure. I dont know why it did not accept the values like 1.1, 1.221 etc.and gave the error "selector values have wrong types" .
So I think case structure should accept the DBL representation of numeric at least upto some digits after decimal point.
When replacing a bundle by name function with an Unbundle by name function or vice versa, the element names should be maintained. Currently when you replace this function with the other, LabVIEW does not maintain the same element names.
The specific issue I've run into is that some newer LV features (like Auto-concatenating loop output tunnels and the expandable Merge Errors node) can be represented in earlier versions of LabVIEW with a more complicated combination of nodes and wires. When "Save for Previous Version" is used, the equivalent code needs more diagram space, but ends up all crowded together on the block diagram.
Here's a specific example (sorry I don't have the original LV2012 source):
In this case, the empty array constant is actually connected to the shift register input of the loop that it is placed on top of. This is completely invisible, though, and very difficult to decipher. In my case, I tried to move that seemingly disconnected constant out of the way and inadvertantly broke the VI beahvior, because the wire was disconnected.
I've encountered this issue in particular when receiving support from NI Application Engineers using LV2012 who build sample VIs for me to test and then need to down-save them for me in LV2011.
I propose that the "Save for Previous Version" automatically clean up the diagram for any nodes that needed to be changed/added in the down-save process (specifically to avoid overlapping and confusing nodes).
I REALLY don't like the Window Tile feature (Window>>Tile Left and Right, Window>>Tile Up and Down). Mostly because Ctrl+T is right next to to Ctrl+R (which I use for showing the error dialog when a VI is broken), so I accidentally tile my windows all the time -- frustrating. I vote to remove it altogether.
See also this Idea: Undo Tile (ctrl + T)
This proposal is about adding a contextual zoom for Labview, but it is NOT a full zoom feature!
According to NI policy: Sub-vi have to be used instead of large vi. So the zoom features are not encourage.
However, Zoom out is already existing right now in Labview using the Navigation Window (Ctrl + Shift + N) in full screen
as explained her :
So, why not transform this into a Contextual Zoom, it could be very efficient to navigate into a vi. as proposed here:
Hope, you will like this proposal
surprised by this discussion, i was wondering how lvlibp's are properly "presented" in custom palettes. The result of my tests are the step-by-step explanation in the linked thread.
Sadly, i have found no official documentation on this, so the initial question is absolutly valid.
My suggestion is to add a comparable step-by-step instruction set into the LV Help and/or make it more intuitive to use lvlibp's on palettes.
Would be great to have an easy access to the mouse scrolling wheel event within any control. In the example below we could zoom in a XY Graph by using X.Range and Y.Range Property, that could be also created as an Invoke Node for this kind of control. I already did it with a user dynamic event and it works great, but took much coding time. I needed to code an event case for "Mouse Enter";"Mouse Leave" to register/unregister the event...
Like in other languages, I want to disable Test/Debug code in exe mode and have it execute in run mode.
Kind property from the Application Control palette can be used as follows.
The KB says "When this property node for a VI or executable is used on a real-time system, the property node will always return the value of Embedded LabVIEW."
So this won't work for my RT application. Makes this even more important.
Also I believe the Conditional Disable Structure should have this as a system defined symbol.
Best regards, Pavan
The Undo (Ctrl-z) menu option is not available in stand alone applications built in LabVIEW.
The LabVIEW help confirms this: http://zone.ni.com/reference/en-XX/help/371361G-01
Look where it says: "Items followed by two asterisks (**) are available in stand-alone applications you build in LabVIEW."
Then look for Undo and Redo in the Edit menu and you will see that they are not followed by the (**).
I posted the code that I created to implement Undo for exes: http://decibel.ni.com/content/docs/DOC-14805, but I believe we should be able to use the "Application Tags" instead of having to create code for something that is already implemented in the Development environment.
Radio buttons, rings & enums are used for the same basic purpose: to allow a user to choose from a list of named options, giveng the programmer an integer result. When trying out different UI designs I am unlikely to want to swap a radio control for a toggle switch or "OK" button. I am far more likely to want to swap it for a ring or enum control.
Currently, if I replace a menu ring with a text ring or an enum, I'll get a new control with the same number of items and the same item names. Often no DB editing is needed.
But if I replace one of those with a radio button control, I get a control with two booleans in it, and I have to recreate everything from scratch.
I'd like to be able to replace a ring or enum control with a radio button control and get a radio button control with as many booleans as I had items in the ring or enum, labeled with the item names. (I'd also like to be able to make that transformation back the other way.)
It would be nice to have an option to "Refresh User.lib" folder without having to restart LabVIEW to save some time required for a LabVIEW restart.
We update software often. Sometimes we need to know which version and build a customer is using.
My executable should be able to fetch that number when it starts up and add it to the Help/About... menu item or display it at the top of the Panel.
When building a LabVIEW executable, the build system knows that version/build number.
Let it format those numbers into a string and write it out to a dedicated textfile or add it to the .INI file.
Then when my executable runs, it can fetch and expose that number as needed.
The current VI documentation editor doesn't have much of the editor toold & functionality supported. Not even Undo will work in the editor. It will be good to have Full fledged text editor for VI documentation editor.
This idea was brought about the Discussion here...
LabVIEW currently searches and returns the FIRST ItemTag match that it comes across, regardless of the Menu hierarchy, which means the user must guarantee that the ItemTag name is always unique.
eg. For the picture below BOTH menu selection examples will return the SAME value ie. ItemTag = Approved ItemPath = Move:Approved. This forces the user to append text to TAGS that will not be unique, requiring extra programming.
I would like LabVIEW to take into account the complete menu path (ie. Top Level and sub-menus) when it searches and returns the ItemTag and ItemPath values. This change will not affect anyone's current code, because LabVIEW does this in the background.
At various times, (including just after I post this Idea), I've editing the LabVIEW.ini file, usually to clean up the initial LabVIEW 2012 screen showing Projects I've created and Projects/Files I've opened. I worry about "accidently deleting" something important, or (because I'm using an ordinary text editor to do this) deleting a bit too much (i.e. two entries instead of one) or not enough (forgetting to delete a semicolon). In addition, not all of these entries should be "presented" to the User, particularly not without documentation!
A LabVIEW Advanced Option to "manipulate" the .INI file could have several virtues. First, it would "know" which .INI file is appropriate for that version of LabVIEW (I have several installed on this PC). Second, it could present the choices in a "logical" way, an array of Paths, for example, instead of a single string of path names separated by semicolons. Third, it omit those features "better left alone". Fourth, it could provide some Help (in the form of either a Help message or an explanatory label, e.g. "Recently Opened Files and Projects") so the User would know what is being altered.