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.
It would be very useful to extend the functionalities of the "Import Webservice" tools to include webservices created and deployed with Labview itself.
Thi feature is already included in Web UI Builder so, in principle, can be included also in Labview.
It sure would be nice if the representation of all numbers that will only be integers were all I32 (same as used for loop iteration, array index, etc.) It is annoying to me when I need to get a window size, a control width, a splitter position, an indicators bounds, etc. and then do some math with them only to find that one is I32, another is I16, then another is U32 ...... the result is lots of red coercion dots and sometimes wacky things can happen with the math if you don't convert everything to the same representation. Same thing for settings like cell positions in tables and list boxes.
This is being discussed lots.. There are replies like, each and every element can't be assigned with property of its own and it may require a huge memory..!! But, there is a property called Index Value which when written with Zero, it returns the Value of the Active element ( The Element visible or last edited element).. And this will be very helpful if just the Index Value can be assigned by us and we get the necessary Value we require..
This will be of huge help and save a lot of time when working with Referencing and array whose Data Type is a Variant (Unknown)., Eg: Unknown Cluster..
I personally believe that this will be possible.. Because, if Memory and all such matters, there wont be a property like Index Value and get its Value alone. We just need to Extend this.. It will be useful in lots and lots of projects..
I select Tools->Advanced->Edit Palette Set to edit the LabVIEW palettes. Now the two palettes ('Controls' and 'Functions') appear, but if they for any reason lose focus (if I minimize all windows, if I temporarily bring another window into focus, or often even if I just left-click click on the desktop), these two windows disappear and it's no longer possible to get them back. I can only see the LabVIEW splash screen, and the Save/Cancel dialog for the palettes (the latter I can't bring into focus).
I'll have to kill LabVIEW through the task manager to start over.
I think the palettes need a bit more work to get them to stay in focus when editing them. Note that this is when editing the palettes, not when using them.
If you change the connector panes of a SubVI with Ctrl + couse, the wiring of the SubVI should automatically change in all VIs which call the SubVI.
SubVI bevore changing rhe connector panes:
Changing the connector panes of the SubVI:
Should not give this result:
It should automaticallya change the wiring.
Debugging is also very difficult if 2 boolean connector panes were changed and the wiring of the SubVI will not change. So the caller VI is executable but the wires are swapped.
This is a bit nitpicky, but I'm submitting it anyway because it is probably very easy to implement, has no drawbacks I can think of, and should have no implications of feature collision.
It would be very nice if there were some kind subtle indicator on the (higher level) block diagram telling you that the subVI's BD will not be visible for learning, modification, or probing. It's not a huge deal to just hit escape and then control+w to go back, but I've been doing this hundreds of times recently, having been inspired to dig through much of vi.lib after reading Darren's weekly Graphical Morsels column.
Hmmm, actually now that I'm putting the graphic together, it's not quite as trivial a choice as I first thought ... how to indicate this without interfering with the wire terminals, not adding clutter somewhere else.
The lower right hand corner seems to be the least busy place of most VI's. The graphic attached would be better if I took the effort to make the key graphic have a transparent background.
Maybe the little key icon should only show up when the user is mousing over the subVI node.
PS Just in case you were wondering, I did not make it a resolution to be as petty as possible in 2011. Pure coincidence on timing.
One of the nice features in the last few versions of LabVIEW is the Shared Variable. Unlike global variables, they can be programmatically created, which would appear to open up a range of new applications for LabVIEW.
Unfortunately, they cannot be assigned default values unless the customer purchases the onerously expensive DSC module. Making matters worse, there is a run-time license associated with distributed copies of an application which uses the DSC.
Naturally, this severely limits the usefulness of shared variables.
This is not the first time that we have seen NI take a key feature which a customer would expect to be part of the PDS, and put it into an optional module. I'm sure that this is intended to “encourage” customers to purchase optional modules.
Our corporate experience has been the opposite - we have seen one of our clients blacklist NI as a supplier, after they were burned by another instance of NI's callous feature bundling.
With using of
„\vi.lib\picture\bmp.llb\Read BMP File.vi”,
it is not possible to load a BMP file with negative height in BMP header. VI returns an error. Please update “Read BMP File.vi” to support complete BMP standard. Negative height in BMP header meaning that the bitmap is a "top-down" bitmap (the image data starting with the top pixel and end with the bottom pixel). Attached is one such image.
When I try to pull a BIGINT value from a SQL database with the Database Toolkit the variant that is returned apparently does not have the value from the database. I say apparently because if you convert that variant to a string you get the data.
My issue is that when the data is in variant format it looks like the data is gone. I think that the value should be displayed to avoid errorneous thinking that there is a problem with my SQL query. This is very misleading and I think the variant value and the string values should match. Otherwise, it looks like there is an issue with my SQL statement.
Here is a screen shot of my code in which this occurs:
I use disable structures and conditional disable structures more and more as my coding starts to spread over multiple targets (Host, RT and FPGA).
I like to include some debugging indicators for my code so that I can (with the proper conditional disable symbols set) debug my code more easily but still remove the bloat for actual release code.
What I have noticed is that controls and indocators which are disabled int his way are NOT accurately represented on the FP. As such I am surrently unable to determine by looking at the FP of a VI that perhaps half or all of the visible indicators are or are not actually being used in the code.
Even when the code is running, the controls and indicatory which are actually disabled are still visible (and supposedly still available over VI Server for example). I think these controls should be actually removed or at least have a visual indication that they are diabled on the BD (distinct to the appearance caused by writing to the "Disabled" property of the control).
The LabVIEW help states: "When compiling, LabVIEW does not include any code in the inactive subdiagrams of the Conditional Disable structure" but I question how true this statement really is.
Although these controls are DISABLED (Not present in the source code)........
Here they are.....
This raises issues on the FPGA level more urgently than on the PC side, but I feel the sentiment behind the idea is the same.
Of course things get more compilcated when the controls are connected to the connector pane, but perhaps simply prohibiting the presence of a connector pane terminal in a conditional disable structure would solve that problem.
When you edit a VI, you may likely move the origin of the pane and not know it. Next time you run it, your controls are not centered. There are several ways to work around this:
How about an option which sets the panel origin to 0,0 every time we save?
.... i.e., an Option which does this for us.
When you open an existing VI, the FP is linked with Windows as the window before the BD. When you create a new VI, this is reversed.
It sounds nitpicky, but it can slow me down a little bit when I have 20+ VI's open.
I actually immediately save and close a VI every time I create one because of this, and then re-open to get the ordering I want.
The probe watch window is not practical. Principially the probe watch window is a nice feature in some cases. But nevertheless when you only just want to place a probe , e.g. a conditional boolean probe, with one click like you are used to do in the past, now you need several clicks to get the same "result": You have to select the probe in the probe watch window again, add an additional probe window explicitely and then hide the probe wath window (because in general it bothers the developer because it covers the blockdiagramms and frontpanels).
My suggestion is to give the option to disable the probe watch window and enable the probe placement like in the past by adding an config entry in the LabView options or a better by adding parameters/shortcuts to the probe watch window.
I really like to use variant attributes for storing different data types. It is very fast and easy to retrieve attributrs (Darin had a weekly nugget on this see here). Now when I look at a variant with attributes I see something like this:
I would really like to be able to extract the text, exactly as it appears in the variant, so I can do things like save it to a txt file. Then I would like the ability to load that text and put it back into the variant. I was very surprised that this can't be done.
Flatten to XML does this:
And flatten to string does this:
While reading Jack's idea HERE I though following:
Switching back and forth between property nodes and method nodes in VI server is a pain.
Why can't we:
1) Have both properties and methods available at the right click menu on the primitive and have LV automatically implement in the background
2) Get rid at the very least of the annoying 4 pixel shift when replacing a property node with an invoke node and vice versa.
1) I would like to see the "radix" visible in the probes for "Numeric probes" and "hexadecimal/coded display" for "string" probes
2) A shortcut to make the selected "control label" in the front panel or block diagram to make it BOLD. (CTRL+SHIFT+B) or anything equivalent
First of all, this idea only makes real sense, when using SINGLE ELEMENT QUEUES (SEQ)!
The idea is, that you dequeue an element of a SEQ and garantee, that the element is returned (enqueued) to the SEQ by using an In-Place structure (see picture).
This would make it impossible to "lose" the data, because of a programming error....