LabVIEW Idea Exchange

Community Browser
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

This functionality is inspired by Microsoft Excel's hide/unhide functionality.

Suppose we have a code like this:

 

OrignialCode.JPG

 

User should be able to select the portion of code he needs to hide, and be able to add a comment on that, something like this:

 

Hide.JPG

 

After he enters the comment, the block diagram would be shown something like this:

 

Hidden.JPG

 

Similar option should be there for "Unhide".

 

The advantage of this would be the user can group a huge block diagram (for example having a flat coding structure) according to the functionality it does, without adding SubVIs to the project.

 

 

Regards,

FraggerFox

I would like a way to rotate the block diagram icons (like +, X, etc.). right now LabView forces me to build programs from left to right. I don't always want to make a bunch of subVIs just to make it easy to fit on one screen view. If it was possible to rotate block diagram stuff 90 degrees (45 deg. not necessary) I could then connect my loop counters (i) easily to a sink that is controlled by what loop I'm on and other applications wouldn't become so large (left to right).

If I build an executable that incorporates any kind of .NET, such as the Simplicity AI PDF Toolkit, it obviously requires.NET on the target computer to work. If .NET is absent, the VI will load as a broken VI and an awful error message is displayed to the operator, typically along the lines of:

 

networkRuntimeError.JPG

 

It would be great if we could place all our .NET code inside a Conditional Disable structure that accepts something like ".NET == True" as a parameter, thus allowing .NET code to run on a machine with .NET installed, but not resulting in a broken VI should it be absent. This would also give developers the opportunity to place something useful into the other case, such as a popup message stating ".NET is required for PDF generation." for example, or even some other replacement code if they so wish.

 

Therefore I would like to see the list of Conditional Disable structure pre-defined symbols include a new one for "Windows .NET"

It seems like it shouldn't be too much to ask for a proper Smith chart (with markers and everything!).  Seems like it's already hiding somewhere...

I would like to see new Read and Write VIs for TCP and UDP connections that worked the same way the Read From Binary File and Write To Binary File work. These file VIs are polymorphic and allow you to specify the format of the data being written or read. With only the current Read and Write VIs available for the TCP and UDP connections we must always include typecasts or other data parsing. LabVIEW obviously has the means to do this since it exists for files. Extend that capability to the newtrok connections as well.

Currently I'm still using LV 2009 so I hope the suggestet feature is not already implemented in the current version of LV 😉

******

 

I'm missing array functions for rotating and flipping 2D arrays. For images (NI-Vision toolkit) similar functions are available.

Of course I can program each function manually but low level functions would be really nice.

 

Let's make an example. The 3x3 input array is:

1 2 3

4 5 6

7 8 9

 

transposing (the only function that is already implemented) deliveres:

1 4 7

2 5 8

3 6 9

 

90° rotation should deliver:

3 6 9

2 5 8

1 4 7

 

horizontal flipping should deliver:

3 2 1

6 5 4

9 4 7

 

vertical flipping should deliver:

7 8 9

4 5 6

1 2 3

 

the cleanup tool is useful and getting more useful each release. however, i still find myself having to cleanup section of code doing bundling and unbundling by hand because it requires manually reordering the names within the nodes. even worse, i sometimes reorder things and then run the cleanup tool again and it decides to move things around such that another reordering is necessary (ick!). let's just give the cleanup tool the freedom to reorder the elements itself. for unbundles it's always safe.  with bundles care must only be taken if a value later in the bundle overrides a previous element in which case those few elements would have to maintain their ordering (which is a fairly low use-case i would guess).  

 

 

cluster-cleanup.png
 

 

When running the NI Developer Suite installer, first detect what is currently installed (as the device driver DVD does) then display it in both the Licensed Product List as well as the Evaluation Product List. This way the user will not doubt what they have already installed. This way you can include option to "Leave this feature installed".

There seems to be little doubt that selecting objects using the old selection rectangle is a "crapshoot" at best.  While I probably won't complain too loudly if that idea is implemented (250+ Kudos, seems plausible), I will suggest a much more modest solution to a very vexing problem for me.

 

Instead of new rules for selection (right to left versus left to right), I propose that LV consistently follow the existing rules.  In particular, the selection of Clusters and Arrays seems to deviate from the norm in a very annoying fashion.  If I clip just a single pixel of a control with the selection rectangle, I have selected the control.  Workable, fairly easy to swipe and select.  Now with a Cluster, for example, if I MISS just a single pixel I end up selecting the contained controls and not the cluster itself.  You get the idea, I select, grab, move, then drop only to discover that I have emptied the cluster or array which sits there mocking me. 

 

My proposal is that selecting a portion of a cluster or array be treated the same as every other control or decoration and select the entire object.

Currently the Listbox/Multicolumn Listbox can only handle Strings which is not always handy in LabVIEW, we need to convert our numeric values to string, manage the decimals, manage the keyboard to validate the format from user entry...

 

It would be nice to have an option on the control as we select scalar/array for the selection method, to select string/numeric data content, and then in numeric we could select the representation that we need, I32/U32/Float...

 

When a cell is editable, it would only accept numeric content, without extra programming, as we would be typing in a Numeric Control.

 

When the option is chosen, the property node would offer something like an orange "ItemValues" instead of pink "ItemNames". 

 

It would look nicer than a 2D array of numerics which can't have row/column headers. Every cells have the same properties in an array, it's not possible to format each cell separatly. In a multicolumn listbox we can set a background color on a specific cell and so on...

Make projects aware of the content of other projects so that you can join multiple projects into a master project. You should then be able to access the contents of each sub-project from the master project.

 

----------------------------------------------------------------------------------------------------

 

Scenario: You have multiple projects and want to build applications in each of them and then create an installer that includes all these applications.

 

If everything was in the same project you could just select all the build specifications and build everything in one go, but today's solution is much more cumbersome: Manually build each of the projects and then have a separate installer project that is based on auto-populating folders pointing to the outputs of the sub-projects...Or - create code that autopmates it for you...Or - forget about having spearate projects and put everything in the same project...(remember to avoid any VI naming conflicts).

Reporting labview bugs is too complicated.

I suggest that a "Report bug" item is added to the Help drop-down menu in the programming environment.

I know that when I'm coding and I'm short on time I always work around the bugs I find, never reporting them because I don't have the time for it.

 

A built in report feature where you can write an error description and an ENUM with the following entries:

No added info

Add screenshot of code

Add current VI

Add entire project

 

A category ENUM might also be appropriate.

 

Evaluation of the reports, etc. 'Best bug report of the month" could be posted on the startup screen news to further increase the use of the tool.

 

The error that made me post this is the following (it's so small that I'd never report it in the current setup):

Start Crtl-Left mouse dragging in a structure to expand it out into an area where block diagram free label arrows are pointing to nodes on the structure. This will break the arrows making them point at nothing (or rather the inside of the expanded structure instead of the nodes). It isn't auto fixed unless you double click the arrows and persists through reloading.

 

If this feature already exists... then it's too hard to find Smiley Wink (at least for me)

Many times, we are working on a LabVIEW code developed by someone else and hence we are not totally familiar with the front panel grouping, unless we try one at a time. Let me know if there is some special trick to understand the groupings.

 

If you try to delete an item belonging to Front Panel group from the Block Diagram, nothing happens.

 

It will be nice to at least get a dialog about it which will not keep the user wondering about the behavior.

 

It will be really nice if it is possible to delete the selected item of a Front Panel group from the block diagram.

I'm trying to manage the properties of my LVLIB, and it's annoying....

Normally, for a VI I would open the VI, and then right click the icon and choose VI properties.

Well, LVLIBs don't have an icon in the upper right corner to do that with (they probably should have one -- the default icon template that I configure in the properties -- why should editing the icon template require me to go through some other weird location -- I already know the icon is the upper right corner of the UI).

So since I can't right click the icon and choose VILIB properties, I go to File -> VI Properties.   ##$%$%^#$% That doesn't work either

lvlib_properties_2.jpg

This doesn't work no matter what is selected in the LVLIB (selecting a VI or the parent LVLIB element, or nothing).

Strike two for doing something I know to find the properties of the LVLIB.

Finally I found you can right click on the parent item of the LVLIB and find a properties selection

lvlib_properties.jpg

So I can get my job done, but why is this so hidden.  It doesn't follow any of the other ways I've learned to find the properties, and to boot the properties window looks totally different between the LVLIB and the VI's

LVLIB:

propscreen_lvlib.jpg

and for a VI:

propscreen_vi.jpg

 

So How about this as a suggestion:

1) make the properties screens be similar (I realize they won't have exactly the same options or settings, but having two very different looking UI's for doing the same thing is confusing).  I kinda like the LVLIB one better than the VI one...

2) support File -> properties when you are in a LVLIB to open the properties dialog

3) Since LVLIBs really have Icons (as evidenced by being able to edit their icon template for children) how about having that in the normal location (upper right corner of the UI) we expect from VI's, and being able to click on it and get similar menus.

 

I'm cleaning up some code that has a lot of stuff like this (much simpler sample code shown):

Loops

The loops are (almost) the same. The normal way to clean this up would be to create a subVI like the following:

Normal

But this has problems. (1) Need to create reference on the calling diagram (2) Reading and setting values by reference (3) Doesn't handle the third loop which has an absolute value. You could deal with #3 by dynamically calling a subVI or having a case structure with an input, but that complicates the design and doesn't make it as flexible (reusable).

 

What if we expanded the idea of inline VIs introduced in 2010. Instead of the compiled code being added to the calling VI, the actual G code is added with input substitutions and then compiled. The 'Macro VI' is replaced by the code inside the VI and the gray placeholder controls/indicators are replaced by the calling VI controls and indicators. This is different from the current inline implementation in that the macro code would be reading the controls/indicators/locals during each iteration instead of just getting the values when the subVI was called. (I believe that is how things are working now, correct me if I'm wrong).

Macro1.png

To handle sections of code that might be different, we could add something like 'code fragments'. Here's an example:

Macro2.png

The orange 'code fragment' gets replaced if wired. The inputs/outputs of the code fragment would have to match.

 

I realize there are issuse if the input controls/indicators have branched wires, etc. Just throwing it out there.

I find myself intuitively reaching for Page up and Page down when trying to move up and down through a Block diagram.

 

I think it would be cool if we coulf "scroll" up a window height at a time when pressing Page Up.  Of course this should work also for the FP, event hough the uses there are probably less.

 

And yes, the caveat that code shouldn't require this is till valid and proud we are of all of that but we allow block diagram sizes of what, 16k x 16k or something?  Wee could use this help.

 

Shane.

This is such a fundamental and basic function, it shouldn't be a $1000 add-on.   Us programmers making careers writing Labview need it to spread more and I think not including basic control functionality like this could be seriously limiting its growth!  Many programmers like me can't actually buy it because there is no way I can justify the cost to my boss.  Instead I'm wasting programming time making my own and ending up with an inferior result which just makes LabView look bad.  

Hello,

 

I love to align my controls on Front panel and I like to be base on my grid.

When you want to make your window multiple of your grid you have to be cery precise with your mouse and set to current panel size or do the calculation depending of the size of you grid.

 

Addind a simple indicator inside Window Size of the Properties window of the VI will help without a lot of effort.

 

Grid Multiple Idea.png

 

This can be added inside "Window Run-Time Position".

 

Best regards.

Create an easy way to go back to the previous view you had on the block diagram. Would be useful when stepping through case statements, event structures, debugging code on larger diagrams, etc. Also, a split screen feature would be nice. Being able to look at 2 parts of a block diagram, different case statements, etc,  sometimes is useful. Support for 2 monitors screens for that feature would be nice also.

Almost always when I use enums in a case structure I want them sorted. As I change and add elements to a type def enum I have to go through my case structure(s) and sort them manually. Why not have case structures auto-sort enums unless an different order is specified?