Leaderboard

A VI is both beautifully and grossly overloaded to be many things. Give it a conpane and inputs/outputs -- bam, a VI is a function. Give it a loop -- bam, it becomes a process. Give it some outbound messaging transport mechanisms -- bam, active object. Give it an Event Handler Structure -- Bam. Actor. (To be fair, a VI is an actor all along... down to even the Space Constant... just many levels of pared-down actors) Now, start composing each of those roles into collections -- you get APIs, then libraries, then systems, then applications. Each of these levels of VI definition and collections of VIs requires different semantics and programming styles. I see the limitation of one Event Handler Structure per VI as a decision that has the potential to significantly improve our abilities to build the higher-level abstractions in LabVIEW that are currently laborious and suboptimal. For instance, this opens up new possibilities to expanding the API of VI Reference instances -- we can start to drop existing primitives (like Generate Event) onto a VI Reference, since that VI has defined itself as being able to handle a set of messages that it can receive, and could even declare types. Imagine: a VI could declare its asynchronous API (rather than having to manually route the plumbing yourself as a dev -- we rise from procedural definitions of behavior to declarative definitions. Though, perhaps this declarative definition is stored at the LVClass level and then routed to a handler process within the class? We can skin the cat a few ways; different syntax, same semantics.) Singletons, single instances of APIs or syntax -- those can be limiting or even crippling -- but right now I don't feel this proposal falls into this category. Now, if we were talking about only allowing one Event Registration wire (this one: ) -- I'd fight this tooth and nail, since it destroys semantics of a thoughtfully-designed active object in LabVIEW. (Spoiler: this wire and the Register For Events node, contrary to popular belief, absolutely have an N:1 relationship with any arbitrary Event Handler Structure) The Events API is perhaps my favorite API in the entire LabVIEW language -- syntax is gorgeous (five nodes and structure) and semantics are even better. Event-driven programming is the backbone of anything I create. Those of you who saw my NIWeek 2013 presentation are aware how excited i get on this topic! :-] I say this, just to emphasize good faith and optimism that even though we're discussing a restriction, what we're really talking about is bounding the bigger picture that could enable much cooler things. As with the other comments above, I'd be disappointed if this proposal is meant just to weld on the training wheels, yet incredibly excited if it's to enable better syntax and VI definitions for building systems. I'm just curious for OP to reveal a larger surface area of his genius and roadmap than a simple, controversial question.

So here's a personal project I've been working on for a little while. Basically it's a LabVIEW version launcher, with a few other useful features. I developed this for my own benefit, and it has helped with my productivity, if you don't like it or think it's unnecessary that's fine you're welcome to give your opinion, but I find it useful and for that reason I'm putting it out there for others to try. What this program does is adds a icon in your system tray (by the clock) that you can right click, and launch any version of LabVIEW installed. If you try to launch a version of LabVIEW that is already running it will bring it into focus based on it's processor ID. You can also right click the icon and launch any version of TestStand installed. This has not been tested very much and it may not work properly. You can also right click the icon and kill any version of LabVIEW that may have hung or is unresponsive. This performs a taskkill on any one version, or all versions of LabVIEW running. You can also right click the icon and abort any running LabVIEW VI in any version of LabVIEW (after you configure the program to use the right ports for you versions of LabVIEW). There is a limitation with this at the moment where it can't abort a VI that was opened from a project file. Not sure how to get around this any help is appreciated. And lastly what this program does is whenever a VI is ran in windows (double click a VI) this program will take over, and determine what versions of LabVIEW installed it can be opened with. If more than one version is suitable then it will ask you what version to open it with. Here it will also show what versions are running and which one is the default version. By pressing (or holding) CTRL when the window comes up it will open the VI with the default version of LabVIEW. This can be changed by double clicking the icon in the system tray to open with the default version, and only ask which version to open it with by holding CTRL. Now that you're interested here's how to use it. First you'll need to download and install an ActiveX component, that allows you to make icons in your system tray (posted by KileenC here). http://forums.ni.com...IEWTrayIcon.zip Then download LV Tray Launcher EXEs Only LV Tray Launcher EXEs Only 1.0.zip If you have LabVIEW 7.1 runtime installed, run LVTrayLauncher.exe. You should now have an icon in your system tray that looks like a space ship. If not check your task manager and see that both axsTrayIcon.exe and LVTrayLauncher.exe are running. If they aren't kill them both and start axsTrayIcon.exe, then start LVTrayLauncher.exe. If you don't have LabVIEW 7.1 runtime installed I do have a runtime less EXE but I'm not sure if it's legal to post it since it contains files that are NIs and I would be copying them to my own server. Any opinions out there about the legality? If you want to see the source, it's attached and saved in 7.1. There is also a readme in each of the attachments with a little more insite into the application. Alot of the source is just pieces of code from LAVA and NI's forums, I tried crediting everyone in the about window, but if you see some code that you think may be yours please let me know so I can give proper credit those that helped. Any questions or comments are welcome, but I don't know how much spare time I'm going to have to support this. So sorry if this is the only version ever released. EDIT: Forgot to mention, here the packages I used: nirsc_html_help_common 2.0-1 oglib_array 2.7-1 oglib_error 2.3-2 oglib_lvdata 2.9-1 oglib_string 2.6-1 oglib_time 2.3-2 oglib_variantconfig 2.7-2 ogrsc_dynamicpalette 0.18-1 Tray Program Source 1.0.zip

Lets say you have a set of customers that each have some version of LabVIEW run-time engines installed, but not sure which ones. You can't build a LabVIEW EXE to give to them because you don't know which one they have installed and if you give them a 2013 EXE but they only have 2011 it won't run. You could send them an installer with the 2013 RTE but that is ever growing and can be a pain to download when the customer isn't sure if they need it or not. Well my idea is to use AutoIt to get a list of the LabVIEW versions (development or Run-Time) and then choose to run a EXE built in a version that is compatible with the version installed. This means building your EXE in multiple versions of LabVIEW and for larger applications this may make less sense then just distributing the full RTE for a single version of LabVIEW. Attached is my source. Extract it and you have a Source folder with the project and VI that just reports the LabVIEW version and path. And a Builds folder which has the AutoIt source (au3 file) and the built EXE from the au3. This EXE should run on any version of Windows XP and newer. Then there is a folder of EXEs all built with different versions of LabVIEW but from the same source. When the AutoIt EXE is ran it finds a RTE compatible with an EXE that is included and runs it. In the zip is version 2011, 2012, and 2013 but to add others just add the folder and EXE named the same as the others. I wouldn't be surprised is someone like JKI or Wirebird Labs has done something like this in the past but I thought I would share what I have done anyway. My use for this is with a new and improved version of my LabVIEW Tray Launcher. It is assumed if you are using the tray launcher that you have a version of LabVIEW installed, but which one? I could distribute multiple versions in a single installer, and then have the shortcut launch the AutoIt EXE which decides which LabVIEW EXE to run. I haven't fully tested it but it appears to work properly. EXE Test.zip