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!

I agree with that: "...when advanced users know what they are doing, powerful things can be done with these tools." Yes, they can be misused by those who don't know what they're doing, just like an FGV can devolve into what I call a DGV (DYSfunctional Global Variables) by not making them An "Action Engine". But that doesn't mean to me that NI should somehow preclude the use of them. In general without knowing the actual benefits of such a restriction it really doesn't make much sense to me. Far easier to say: Use more than one Event Structure with great care and attention.

Jack, I can agree with all of your statements, esp the last one about what's the real objective, what's the vision of imposing this restriction. If it's training wheels (which is my fear) then I'm definitely opposed. If on the other hand a carefully crafted and developed approach implementing what you've described would be simply amazing and wonderful. I guess I'm from Missouri on this one: I want NI to "Show Me".

Have you tried the "copy the project to a new name" trick?

FWIW the word that I got early on was "ONLY ONE ES!!" so I haven't even tried to use more than one on any BD, but I have encountered situations where I really did want to do that. The main reason was so that I didn't have one enormous ES. And in that regard: what's with not being able to reorganize the Event States? Or do I just not know the "trick". My vote is not to remove the option for more than one ES per BD.

I agree with AQ on this: ie I have found 2013 to be very stable.

Hoovah's suggestion is certainly failsafe; however, I have a question for the OP. What's the purpose of the rename? Depending on the rename's purpose you may want to consider using a branch: e.g., if the renaming indicates an architectural change in the overall software. Otherwise, if the renaming isn't indicative of some larger "structural" issues, why do it?

The simplest solution is generally the best. Limit new users to 1 post per day for the first month. A month might seem harsh but, over time, that "quarantine" period could be decreased until we find the minimum above which spammer bots don't pursue; and I suspect that might end of being a week or less. An additional factor would for regular users to be able to flag a new user suspected of being a spam bot as "spamming" so that a LAVA moderator is alerted to ascertain what is happening. Yes, they ARE incredibly annoying...

Yes to your first point and also yes to your second; however, one can hack around the LabVIEW community pretty well too. Search the CR here or the NI website, or, or, or and there are plenty of sources from which one can utilize already developed toolkits, code samples, etc. This allows you to see good coding techniques -- as well as some less than optimal ones -- and also come to understand licensing arrangements, etc. Not to mention start up some very good collegial relationships.

I find this perspective curious because any "thing" that accomplishes a task is an instrument, whether that task is measurement, display, file management, byte manipulation, etc. LV is virtual instrumentation because everything is in code -- not hardware. Whether something is an instrument is not about having or not having a user interface that is visible; rather, it's like the concept of having a tool that "gets the job done". Frequently the military serves as an instrument of a political decision and that includes black ops.

Right. LV is "coding by cartoon" but text based is actually "coding by typewriter". So you're using technology (viz the layout of the keyboard) that was standardized in the 1920's specifically to SLOW DOWN typists -- so the mechanical typewriters of the day wouldn't jam. No one is even using the Dworak keyboard arrangement (http://en.wikipedia.org/wiki/Dvorak_Simplified_Keyboard), which was at least developed in 1936. That all DOES seem much more advanced than having fun and "coding in cartoons", doesn't it?