Val Brown

FWIW, this thread so far confirms its original premise, reveals what "the baby" is and what "the bathwater" is.

I've running LV 2015 on W10 since before NI Week and, once I got it set up, it all seems to be working fine. Yair I was able to pin a number of "arbitrary" apps to the Start Panel but it's a bit of an uncertain and occult process: I can't tell what actually worked and what didn't. One thing I did find out was that pinning an app to the Taskbar helped as a first step, but your local results may vary.

There are two things I'd like to say about this thread. 1. It underscores for me how often CLA-level "in-house" projects are undertaken that run more or less in parallel to other such projects. In some ways this is a very good thing as it allows for diversity in approach and implementation but also a robust degree of competition that, hopefully, increases the overall qualitym usability, scalability and extensibility of the various offerings. We have some very brilliant and creative people in this community! But there is also a downside to this diversity and that involves confustion to the populations end-customers who look for well done implementations of whatever "needs to be used" so that their requirements are met. I mentioned the idea of conmsidering some form of "steering committee" to at least somewhat coordinate all of these efforts so that there isn't just a glut of competing toolkits overwhelming the Tools Network. 2. The second point concerns this following specific exchange (just above): Quote So if I needed a CAN actor for doing CAN communication, I would make that actor and call it in parallel with all the other actors. They all started at the same time, and all stopped at the same time. No actor ever shutdown, without sending a message to shutdown the other actors. We wanted to make it possible to restart a module without having to restart the entire application. I continue to work closely with Delacor and greatly appreciate this specific feature in the DQMH. My project calls other stand alone 3rd party software that can be separately shut down by an end-user and we need to be able to restart that separate EXE asynchronously when that happens, however it did happen. To be clear, it is impossible to prevent or trap that end-user action (to preclude that 3rd party EXE from being shut down) so we have to be able to detect when that has occurred and then restart the previously shut down 3rd party application autonomously, without further input or interference from the end-user. The DQMH supports this essential functionality. Other approaches might well be more appropriate in other specific situations (as in “Your mileage may vary…â€) but overall I think this is an extremely well implemented Template. ​

I'm in. See y'all there!

I agree with this. If it compiles -- even it it's "wrong" in what it does -- then it should not "break" in the IDE. Some form of warning that CAN be ignored by those who want to do so, is really the best solution, even if there are lots of LV programmers who routinely ignore errors that are generated by the IDE. In other words, if you really want to setup what some would consider to be a "race condition" then the language should allow for that. No matter how thoroughly the original architecture of the underlying language, there will be "holes" and possibilities that developers will propose based on their own idiosyncratic, "advanced" explorations around what is perceived by them as limitations in the language. After all it is an iterative process in the end no matter what else you may want to believe.

I've built EXEs from code that was migrated -- and updated -- along the way since LV 6i and I've not seen this kind of issue in either 2014 0r 2014.

Putting legs on the snake....

This is probably a WAY silly idea but did you try setting the working directlory to usr/natinst/LabVIEW-2013/ and then just using labview as the command line (perhaps having done a cd usr/natinst/LabVIEW-2013 first? That might at least generate some other error messages...

It's interesting to believe that 10 or more years old keyboard and mouse based (not even trackpad) UI is going to remain the prevalent benchmark. I strongly suspect that touch interfaces and other gesturing (perhaps some kind of "Leap" process) will supplant physical keyboards and mice like they supplanted punch cards and magnetic tape. MS doesn't have a great track record in developing, let alone inventing, UIs so I also strongly suspect that it will an iOS style user experience that will continue to "lead the way" (as what the US Army Rangers do). It's intuitive -- unless you have years of physical keyboard, mice and File>> kinds of meaning -- and that is what users want. It really is that simple, esp now that XP is going to whither on its own vine.

I thought that was already well known back in the early 80s....

OK, thanks. All info, tips and suggestions welcome....

Still wondering if anyone is using ubuntu to support LabVIEW for Linux?

Will this be a new "add-on"?

Outstanding! Great idea and great first guests. as the saying goes: "Break a leg..."

Another taste piece of code from the Captain. Nicely done!