LabVIEW Idea Exchange

I think it would be nice if LabVIEW was smart enough to know that when I drop a For Loop around scalar inputs it doesn't auto-index output tunnels - but rather uses Shift Registers - for matching inputs and outputs.

The common use case for this is with the Error input/output - it annoys me how it becomes an Array output.

As it is already wired, inline and not broken, dropping a For Loop around it should not break my code! 

Reference or Class inputs are other use case too - I want to pass the same thing around not create an Array. 

Shift registers are better than non-auto-indexed tunnels (other option) as they protect the inputs on zero iterations.

This would remove one step required for most use cases, speeding up my development experience.

I really like the changes to the Create Data Member Accessor Screen in LV2009 (and LV2010).

I like the Place new accessors in this folder logic.

One thing that would be cool to extend on it would be if the screen allows you to set the scope of a new Virtual Folder at the same time.

This would save time as you would not have to right click and set the scope of the new Virtual Folder from the Project Window the first time it the Virtual Folder is created.

If the Virtual Folder already exists in the Class then this option should be grayed out and disabled.

This Idea applies to all Libraries but my main Use Case relates to Class Libraries

I am not sure how everyone arranges there Classes, from trolling online it seems common that non-publically scoped methods tend to get placed in their own Virtual Folder and public methods are at the top-level. 

 For example:

Unless my Class only has a few methods I would take a similar approach however, most of the time I like to categorize them in more detail. The reason being this is my palette from where I choose my methods, and I like to group them using the following logic so that I can get as much information visually out of the organisation / layout of the Class. I like to have the only top-level method as the constructor if there is one (so I can see that there is one or not for that Class).

I only create the Virtual Folders I need, but usually there are a mix from the follow example:

The problem I have with the current design is that I don't know whether I have scoped my public methods correctly, as I could have forgotten and they are still left not specified - which is the default when you create a new Virtual Folder. 

Currently there is no way to tell the difference from the above two Virtual Folders unless you right click on them or possibly look at the contents.

This is not great as there is potential that I could have scoped things wrong which normally leads to me having to check or recheck the scope is correct.

As LabVIEW is graphical by nature, it would be much nicer if I could visually see a public scope glyph to differentiate it from a not specified Virtual Folder.

I selected the color green as it is a natural opposite to red (private) and has not been used yet.

For example:

Therefore, my original implementation would look like the below, and I can straight away see if I have scoped the public folders correctly.

I am sure there was a reason not to include it originally.

I am interested to why and if there is a good reason not to show this too.

At the moment you can Register for Events using a Cluster of Refnums.

But you cannot Destroy User Events or Unregister for Events in this way.

This approach allows for you to scale your application without the need to change the code that handles Registering Events.

It would be very convenient to be able to close references in this way (using a Cluster of Refnums) too, as per my illustration below:

Support LabVIEW-UML integration.  Integration means supporting code generation from models and reverse engineering to models.  The UML tool must support the latest UML specification from OMG.  (This includes the specifications for interoperability.)

Other considerations when selecting a UML tool should include:

UML features and ease of use of the tool.

Support of SysML.

Integration with version control.

Additional features of the tool.

Cost of a license.

Size of user base.

When I want to insert a line of text in the Enhanced Icon Editor of an existing VI it usually means I have to overwrite my existing text or cut and paste it.

I.e. If I simply want to go from this:

To this:

It's not that easy and it could be much quicker.

I would like to be able to Right Click (or a similar method) on the Lines Cluster and select "Insert". 

This would insert a blank line and move the Line Text and Line Colors accordingly, preserving existing settings thus allowing me to easily edit the above icon's Lines quickly and easily.

Hello,

I would like to suggest that LabVIEW support HDF5 for data format, file storage and data transfer.   I would to suggest the support include maintenance to coincide with new and future versions of HDF5.

Thank you.

In Visual Studio you have XML Schema tools etc. It is a breeze to e.g. populate a drop down menu based on XML from a web service, and my first thought when I see it in action is - why do we not have this at our fingertips in LabVIEW already? LabVIEW could have made it simple to create schemas, generate flexible XML etc. You could have wizards that helped you, and cluster to xml conversion like in EasyXML from JKI - and it should all feel fully integrated (toolkits are OK, but this really needs to have native support).

I am currently developing a web service in LabVIEW and the first thing I had to do was to abandon the few in-built XML functions and write my own serialization code (using terminal mode for the web service gave you XML without proper headers, and the in-built flatten to XML outputs XML is impractical in use). Once I have serialized a text table e.g. and published it - using that table feels incredibly easy in Visual Studio (add data source-> input web address etc.) , it would be much more difficult to do the same in LV.

I think NI should make a big leap in the use of web technology. The RESTful web service functionality was a great addition, but the doumentation is non-existing, and we should have come much further by now. I know there are some cool experiments going on with web based GUI editors, but LabVIEW 2010 was just released with very little news on this front so forgive me if I rant a bit...