LabVIEW
"Run VI when opened" from lvproj doesn't work
Solved!
@Hooovahh wrote:So for the most part this feature is old and busted. It probably shouldn't exist at all, and the fact that it does exist stems from NI bending to the will of those who might not know what was best for the language as a whole.
But it sure is nice when I open jcarmody's "abort.vi"... 
@Gregory wrote:But it sure is nice when I open jcarmody's "abort.vi"...
Abort all VIs in all versions of LabVIEW, in all contexts, and optionally from all private contexts, from the system tray you say? (but yes I agree that function is useful)
littlesphaeroid wrote:I am simply trying to make a ally useful "duplicate test template" feature for other developers in my group to use, and double clicking a VI in the project seemed like a great way to get a dialog ot pop up.
Oh well then why didn't you say so? There's actually multiple ways to accomplish something like this.
There is of course the right click Run from the project. But something like this might be more useful in the Tools menu. Imagine a developer with any VI open could go to Tools >> Generate Special Template. NI has hooks to allow for VIs to be ran in the tools menu by just placing a VI in the <LabVIEW Install>\Project folder
http://digital.ni.com/public.nsf/allkb/2ED4443B186788E18625714000757C03
You can also do things like make templates, placing them in the <LabVIEW Install>\templates folder. Now when you go to File >> New... you can open a fresh template VI that won't overwrite the existing VIT file but make a new VI that needs to be saved.
Oh and starting in 2012 there are template projects. That wizard you see when you click Create Project on the getting started window.
http://www.ni.com/tutorial/14045/en/
If you want lots of fun there are also the Project Provider Framework. This allows for making right click menus on things in the Project Explorer. There's not many examples of this, and to be a partner you need to ask NI nicely but there are some who have opened up this API without NI's permission. Still this isn't stable under all cases, and honestly needs to have some attention by NI before I'd consider using it for much, but it is impressive what some have been able to do with this API.
Now how do you install these tools on your developers machines? Well you can manually copy them to where they need to go, or you can look into using VI Package Manager, which makes packages which install files in specific places and have hooks for doing some other things too. The free version can make packages, and install them.
@Hooovahh wrote:Alright lets take a deep breath...
Disclaimer, the following text is my opinion based on my knowledge of LabVIEW and not the inner workings of NI, I could be wrong about why decisions were made:
This feature in my opinion was put in many years ago, as a cheap and dirty way to make it appear as if a VI is executable code (which is sorta can be but shouldn't be treated exclusively as). Years ago if you had some code and you wanted a user to double click an icon and have it start running you would make an EXE. Well that required the application builder which was extra money and it was a decent amount of steps involved. The new users of LabVIEW complained that this was too difficult and wanted a way to just double click a file and have it run so NI added this function. NI also tried making it easier to do by adding additional items in the Tools menu to eliminate steps. Now if you double click a VI with nothing else open, which had this run when opened setting on, it would open and run it in LabVIEW. Running source code as an application has several pitfalls and issues, and in other (non scripting) languages this would not be tolerated. But it was a hacky way to make the beginners of LabVIEW happy.
Later on LabVIEW got projects and a easier way to make EXE (still requiring the application builder). Now using source from a project, looked and behaved more like source from other text based languages. In this regard opening a VI would be the equivalent of opening a text file in notepad. And having the behavior of opening text and having it automatically start running from your source would be a bad thing. The state of source can easily be modified which is one of the reasons binarys should be used in these situations.
So for the most part this feature is old and busted. It probably shouldn't exist at all, and the fact that it does exist stems from NI bending to the will of those who might not know what was best for the language as a whole. That feature should either be removed all together, or be updated to run when opened from a project which I hope I made clear is probably not the best solution. A third option would be to just update the documenation stating the current behavior.
If you want to run a VI when opened use this feature, but open the VI not from the project. Instead just open the VI from your file explorer, or from File >> Open in LabVIEW. Opening it from a project is telling the IDE you are trying to edit the source, in which case it shouldn't run when opened.
The good news is NI has a place where you can suggest new features or improvements for LabVIEW. If there are people who agree with your new idea they kudo it, and enough kudos causes NI to consider these features. If this is important to you, and a suitable work around doesn't exist I'd suggest making a post there.
While I do agree with you about running source code - it would just be wrong to distribute Visual C++ source code intended to be run inside of Visual Studio, for example - I believe versions before LV 3.1.1(?) din't even have an application builder. So it would seem that building the executable was the "kludge" and running straight from the source code was the norm.
I like that you included a discussion about the Idea Exchange. Unlike most product improvement pages, NI really does include stuff from the Idea Exchange in their new releases. One only needs to look at what's new to see all the features that came from the Idea Exchange! (Example: LabVIEW 2015. PS - this is a release with quite a bit less taken from the Idea Exchange than usual.)
@billko wrote:While I do agree with you about running source code - it would just be wrong to distribute Visual C++ source code intended to be run inside of Visual Studio, for example - I believe versions before LV 3.1.1(?) din't even have an application builder.
.
Oh yeah well there's that too. There's always been an application builder in LabVIEW since I started development so I kinda forgot about that.
@Hooovahh wrote:
@billko wrote:While I do agree with you about running source code - it would just be wrong to distribute Visual C++ source code intended to be run inside of Visual Studio, for example - I believe versions before LV 3.1.1(?) din't even have an application builder.
.Oh yeah well there's that too. There's always been an application builder in LabVIEW since I started development so I kinda forgot about that.
I didn't even know this until you went and forced me to go snooping around the internet. 😉
@billko wrote:I didn't even know this until you went and forced me to go snooping around the internet. 😉
While I've never used LabVIEW 5.x for anything other than a lark, I know that it had an application builder, and actually would include the LabVIEW runtime engine in the EXE so no additional NI installer was needed. This was also the first version to include undo.
