LabVIEW Idea Exchange

With the advent of scripting, it is possible to create some nifty tools to aid in code writing.  Those that work on individual elements of the FP or BD can often work nicely in Quick Drop or the Right-Click Framework.  Some of these tools however, work most naturally as an addition to to Tools menu.  The missing piece of the puzzle for seamless integration into the IDE is the ability to customize keyboard shortcuts for those additions.  I would simply like the ability to assign keyboard shortcuts to any item which appears in the Tools menu.  I have at least three things in there already more worthy of Ctrl-t.

As described in the following "Darren's Weekly Nugget" posting, LabVIEW provides an API for programatically building projects. Especially when dealing with large projects, this can be a real time saver and great technique for quality control (ensuring that the build process is carried out the same way each time). However, when doing a programatic build, there is no status information - the LabVIEW application that calls these APIs is just left, giving the impression that it has locked up. This can be especially concerning given that builds of complex applications can take quite a while.

A solution seems pretty straight forward - give the build API calls, the option to display the standard building dialog.

A simple boolean value could allow an API user to provide some feedback to the hosted application as to what is going on without any of the complexities of other status feedback mechanisms (although *any* mechanism would be better than none!)

Weekly Nugget Posting regarding App Builder API: http://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-02-15-2010/m-p/1072575

I did a search on this forum to see if the subject been asked before but couldn't find it quickly, so I post. I have been seeing business push and pressure to move in this direction over the years, more so recently and have migrated to eclipse for my current project and like CDT. I saw the following today and it got me off my inertia to ask/feel the question here. I would venture that Operating systems and other mature s/w tools aren't rocket science anymore, but commodities and open-source w/ customization makes sense. Easier said that done. Thoughts?

pavan

This inspired me to ask the question:  The Eclipse Helios simultaneous release of 39 Eclipse projects and 33 million lines of code showcases the diversity and innovation going on inside the Eclipse ecosystem. In terms of statistics, the Helios release includes 33 million lines of code developed by about 500 Eclipse.org committers from 44 companies. The important thing to remember about Helios and Eclipse simultaneous releases in general is that even though it's a simultaneous release, it doesn't mean these projects are unified. Each project is a separate open source project within Eclipse.org, operating with its own project leadership, its own committers and its own development plan. The simultaneous-release concept is designed to provide a transparent and predictable development cycle.

Other ref:

Microsoft ups the ante in the robotics market, makes MSRDS free ... (see coments from emiliekopp)

CentOS, Ubuntu...

Eclipse & addons

Python

GCC

Octave

Scilab

Android (I think it is open?)

Open-office

ISO formats for docs

Open Car

Open prosthetics

...

The list goes on.

I'd like to see something like a conditional disable structure that would be sensitive to fields in an .ini file at runtime, not compile time.

My problem is that I have an application that can access many different third party cameras. For this application to work every VI that accesses a camera specific .dll function must have assess to that .dll or I get a broken VI. When I compile the VI I have access to these .dlls but when I build an application.exe and distribute it I only want to distribute the .dlls for one of the cameras. If I could distribute a .ini file with the application.exe that indicated which camera the drivers were installed for then the application would disable the code for all the other cameras and the VI would not break.

Thank you,

Chuck Lippmeier

Using the LabVIEW 2009 Build Spec (as an example) allows you to add a Destination to a Library which is very handy, as it means you can namespace VIs at build-time.

I would like to take this a step forward and then be able to set that new Library as a Sub-Library of another Library that already exists in the Project.

I would then want to be able to set the scope of this Sub-Library as well (relative to its now, Parent).

This combined with my Locking State Idea would allow be create a Distribution that would hide and protect a Support VI Library

As the Sub-Library would be Private Scoped (from above) and the Parent Library would be set Locked (does not show Private Members).

I currently can implement this using Scripting but it would be nice to have it native.

Cheers

-JG

Locking a library during an automated build seems like a very natural thing to do.  Would be nice to be able to script it.