Topic about LabVIEW just started on slashdot.org

[bsvingen]

With a bit of theoretical work, you can show that any programming paradigm is "perfect" for just about anything. This doesn't mean that a specialized programming language like LV is a general purpose language just because it uses dataflow. On the other hand, Java is indeed a general purpose object oriented language like C++, but Java is abselutely useless for making low level stuff like drivers for instance. I mean, programming paradigm is only one of several pieces that makes a language "tick" in the real world.

I use LV for lots of things as well, but I have grown more and more sceptical using it for general purposes. The cost is one major issue. If you use it in the lab with equipment costing several millions, this cost is easely justfied. As a general purpose language, the cost is way too high, when looking at the alternatives which cost nothing (Java, C/C++ etc.)

I think most people using LV as a general purpose language, started using it in the lab. Then they got more and more professional with it, and also started using it for other tasks as well (why use a month learning Qt and some more C++/Java when I can do this in one evening using LV? right?) This is all very fine, but sooner or later, if your code base develops, you will get into practical problems with license cost, portability, maintainability, not necessary for yourself but for others and for future development and certainly for future distribution. These are problems that naturally surfaces due to the fact that you are using a highly specialized proprietary programming language. You cannot even legally read the source without a valid license. For a general purpose language this is a big NO NO. These are real world problems that you simply cannot get around untill NI start licensing LV the same way Sun is licensing Java (which doesn't seem to happen any time soon).

Anyway, I'm not saying "don't use LV". I think LV is excellent. But it is not a general purpose language, not in any stretch of the word. If you use it as a general purpose language, you should be aware that you could face unsolvable problems in the future.

[Mark Yedinak]

QUOTE (bsvingen @ Feb 3 2009, 01:38 PM)

With a bit of theoretical work, you can show that any programming paradigm is "perfect" for just about anything. This doesn't mean that a specialized programming language like LV is a general purpose language just because it uses dataflow. On the other hand, Java is indeed a general purpose object oriented language like C++, but Java is abselutely useless for making low level stuff like drivers for instance. I mean, programming paradigm is only one of several pieces that makes a language "tick" in the real world.

I use LV for lots of things as well, but I have grown more and more sceptical using it for general purposes. The cost is one major issue. If you use it in the lab with equipment costing several millions, this cost is easely justfied. As a general purpose language, the cost is way too high, when looking at the alternatives which cost nothing (Java, C/C++ etc.)

I think most people using LV as a general purpose language, started using it in the lab. Then they got more and more professional with it, and also started using it for other tasks as well (why use a month learning Qt and some more C++/Java when I can do this in one evening using LV? right?) This is all very fine, but sooner or later, if your code base develops, you will get into practical problems with license cost, portability, maintainability, not necessary for yourself but for others and for future development and certainly for future distribution. These are problems that naturally surfaces due to the fact that you are using a highly specialized proprietary programming language. You cannot even legally read the source without a valid license. For a general purpose language this is a big NO NO. These are real world problems that you simply cannot get around untill NI start licensing LV the same way Sun is licensing Java (which doesn't seem to happen any time soon).

Anyway, I'm not saying "don't use LV". I think LV is excellent. But it is not a general purpose language, not in any stretch of the word. If you use it as a general purpose language, you should be aware that you could face unsolvable problems in the future.

In general I agree with what you say however you are referring mainly to the licensing issues of the language, not the language itself. While the licensing issues are a major concern there is nothing in the G language itself that precludes it from being a general purpose language. As with any tool it can be said that it may not be the best language for a particular situation but this can be said about any programming language. Your example of Java is a prime example.

If you look at my earlier posts I have been saying that I believe NI needs to address the issues that you raise so that LabVIEW can be positioned better to become a general purpose programming language. Currently we are basing our all of our automation efforts on LabVIEW. Many of the issues you raise are not as much of a concern because our automation efforts are all internal to the company. Licensing and distribution is more controlled in my environment.

I choose LabVIEW for a number of reasons. I am a CS major and spent the first half of my career working with C, C++ and assembly working in realtime embedded systems. For me I find that I am much more productive in LabVIEW than any other language. This negates much of the cost issue. The additional cost for the license is easily recouped by the time it has saved me implementing something. LabVIEW is one environment that easliy migrates to the multicore environment and can take advantage of it with very little effort on my part. A standard C++ application will not be able to make that same transition without some significant development efforts. Many of the things built into LabVIEW don't come for free in other languages. But until NI does a better job at promoting and supporting LabVIEW as a general purpose programming language it will not be seen as one. I think this is the cruxt of this entire debate.

[bsvingen]

QUOTE (Mark Yedinak @ Feb 3 2009, 09:03 PM)

But until NI does a better job at promoting and supporting LabVIEW as a general purpose programming language it will not be seen as one. I think this is the cruxt of this entire debate.

I am sure if they did promote and license LV as a general purpose language the same way Java is licensed, the user base would expand tremendously to put it mildly. We can only hope, some day

[Val Brown]

QUOTE (bsvingen @ Feb 3 2009, 03:18 PM)

I am sure if they did promote and license LV as a general purpose language the same way Java is licensed, the user base would expand tremendously to put it mildly. We can only hope, some day

I think it's highly unlikely and incredibly naive to believe that NI should "market" LabVIEW as if it were JAVA. Not only is there no real need for NI to do so -- unlike the situation facing Sun when they sourced Java -- what would really be the advantage? One posted cited cost as a factor making LV not be a general purpose language. I think the real issue was that it does cost, so it is a low-cost general purpose language. Other options APPEAR to be low-cost because for the "pure" base language and IDE the cost IS lower, initially. But, as I pointed out above, the learning curve for other languages as well as the cost and need for additional "add on" libraries, etc makes the overall cost far, far HIGHER than using LV.

I've never had a problem distributing my built apps, at least NOT with the LV portions. Where I have had problems over the years was with all of the OTHER components and "pieces" that were written in C/C++ and VB. A big part of my efforts over several years involved completely removing ALL of those other portions, so as to simplify my distribution and maintenance issues. To say this another way, you couldn't pay be enough to NOT use LV and move to another environment with what I'm doing. And bear in mind I started out as a unix and C hack back in the day (as the saying goes). I am SO thankful to be out from under ALL of that nonsense and that is all because of LV. I only wish the rest of the initial team had headed my advice and ONLY used LV. It would have saved me thousands of hours of re-programming, re-factoring time.

[jdunham]

QUOTE (Val Brown @ Feb 3 2009, 04:15 PM)

I think it's highly unlikely and incredibly naive to believe that NI should "market" LabVIEW as if it were JAVA. Not only is there no real need for NI to do so -- unlike the situation facing Sun when they sourced Java -- what would really be the advantage?

Well the advantage would be that the user base would probably increase by a factor of 20 to 50 in short order (wildly guessing of course). The world would be divided into people who use LabVIEW or who program "the old-fashioned way". What if 80% of the kids in the USA would have built a LabVIEW-controlled robot by the time they reached 10th grade?

I have no doubt NI evaluated this future and decided it was too risky and that they didn't know how to do this in a way that would benefit their shareholders. I don't know how to do this either, but I don't agree that this it's naive to contemplate it.

[Val Brown]

QUOTE (jdunham @ Feb 3 2009, 07:04 PM)

Well the advantage would be that the user base would probably increase by a factor of 20 to 50 in short order (wildly guessing of course). The world would be divided into people who use LabVIEW or who program "the old-fashioned way". What if 80% of the kids in the USA would have built a LabVIEW-controlled robot by the time they reached 10th grade?

I have no doubt NI evaluated this future and decided it was too risky and that they didn't know how to do this in a way that would benefit their shareholders. I don't know how to do this either, but I don't agree that this it's naive to contemplate it.

The naive part is, IMO, the idea that it will open source, low (initial) cost a la C/C++ compilers. The idea that LV will ultimately become a dominant IDE is pretty obvious.

[jzoller]

Some random thoughts on general purpose LV.

First, I have more thumbs than there are major companies that make money from selling general purpose languages. Most major languages are either open source (free-as-in-beer), or are loss leaders for companies selling platforms (Microsoft).

Second, the test hardware niche is really comfortable for NI. Imagine Microsoft came up with LV.NET: an exact, general purpose clone of LV, just without the hardware access. Would NI sales suffer? Almost not at all: NI is a hardware company. In fact, sales might even increase as more users find this really "new" language, and discover this rip-off that NI has made isn't half bad either

Third, making LV general purpose requires NI to take market share away from the major players already entrenched in the field, at a not insignificant cost. It almost certainly also requires they adhere to a more broadly accepted standard of some type as well, making development and maintenance more painful.

However, I agree with jdunham that the "threat of conversion" is very real. Last place I worked, we were told (by executive fiat) to retool everything in C# and C++. Pointing out the multimillion dollar investment loss and 2 year downtime seemed to cool the executive enthusiasm, and this made them mumble something vague about carrying on with LV and go back to counting their bonuses.

Watching LV restrict itself to its market niche is like watching Tiger Woods decide to only play mini-golf, but if mini-golf is where the money is...

[Val Brown]

QUOTE (jzoller @ Feb 3 2009, 08:42 PM)

...making LV general purpose requires NI to take market share away from the major players already entrenched in the field, at a not insignificant cost. It almost certainly also requires they adhere to a more broadly accepted standard of some type as well, making development and maintenance more painful.

I don't think so. LV is setting a standard -- a true visual interface. And, if I'm not mistaken, some matured form of LVOOP will eventually consolidate and remove THAT perceived barrier. One other innovation that I think could really help with general acceptance would be completely transparent C/C++ text-based interface in the mode of the Math Expression node. I KNOW it's not at all easy but, if it were done, it would really make it a no-brainer for the "text-uber-alles" crowd to really "get it" about LV's capabilities. That might even make some other code more "readable"...

QUOTE (jzoller @ Feb 3 2009, 08:42 PM)

However, I agree with jdunham that the "threat of conversion" is very real. Last place I worked, we were told (by executive fiat) to retool everything in C# and C++. Pointing out the multimillion dollar investment loss and 2 year downtime seemed to cool the executive enthusiasm, and

this made them mumble something vague about carrying on with

LV

and go back to counting their bonuses.

In the end dollars DO count and I believe that IF companies (and individual programmers) actually counted the REAL costs of using C/C++, JAVA, etc they would come to see just how cost-effective LV really is.

QUOTE (jzoller @ Feb 3 2009, 08:42 PM)

Watching

LV

restrict itself to its market niche is like watching Tiger Woods decide to only play mini-golf, but if mini-golf is where the money is...

To say it that way does sort of imply that LV is a bit of a toy or game.

[jdunham]

QUOTE (Val Brown @ Feb 3 2009, 09:52 PM)

To say it that way does sort of imply that LV is a bit of a toy or game.

No, he was implying that test & measurement is like a toy or game compared to the big-boy world of consumer products and business applications. Think about HP and where their test & measurement business went. It was basically too small to bother with, so they spun it off. If 20% of Americans knew how to use LabVIEW and if X10 home automation were replaced by NI products and were in 30% of all dwellings and 90% of new construction, NI would probably be selling its T&M business to Jim Kring. Since HP went through exactly the same thing, you can be sure that NI has at some point tried to figure out whether they could pull this off.

[ACS]

QUOTE (jzoller @ Feb 3 2009, 09:42 PM)

Imagine Microsoft came up with LV.NET: an exact, general purpose clone of LV, just without the hardware access.

I recall having a conversation with an NI person at NI Week some years back. This fellow told me that, in large part, this is exactly why NI markets almost exclusively to the "no programming" crowd - it keeps LabVIEW under Microsoft's radar. NI did not want to get into a shooting war with Microsoft the way that Netscape did over browsers. MS has very deep pockets and could take a loss on a new programming tool for years - long enough to successfully undercut NI's LabVIEW sales. NI may be a hardware company, but LabVIEW sells a lot of that hardware for them. The result of such a war could be disastrous for NI, and, incidentally, all the rest of us who would be forced to use the new, inferior product.

It does make our jobs harder, and it's infuriating to hear someone bad-mouth what I do because they're ignorant of their own shortcomings. OTOH, it means I'm a rare, highly-qualified specialist in a demand market, which is a good place to be these days...

[bsvingen]

Java is not open source. It is proprietary and closed, but free (as in free beer). The difference between java and LV from a "high level commercial" point of view, is in fact price only. But there exist another programming environment, Matlab, that is general purpose in nature and much more expensive than LV, still it has a much larger user base. With Matlab it is also possible to make stand alone executables, yet extremely few use Matlab to make general purpose programs.

There is also a Matlab open source "clone" called Scilab. It even has a LabVIEW node that can be used. Everything is open source and free and supported by NI it seems. I tried it a few months back, and it seems to work just perfectly (if I only could find some real world use for it ).

[Val Brown]

QUOTE (bsvingen @ Feb 4 2009, 12:30 PM)

Java is not open source. It is proprietary and closed, but free (as in free beer). The difference between java and LV from a "high level commercial" point of view, is in fact price only. But there exist another programming environment, Matlab, that is general purpose in nature and much more expensive than LV, still it has a much larger user base. With Matlab it is also possible to make stand alone executables, yet extremely few use Matlab to make general purpose programs.

There is also a Matlab open source "clone" called Scilab. It even has a LabVIEW node that can be used. Everything is open source and free and supported by NI it seems. I tried it a few months back, and it seems to work just perfectly (if I only could find some real world use for it ).

I think that, again, you make one of my main points. What differentiates Matlab from LV is that Matlab is TEXT! So, yes, the text-based "crowd" really likes it and it is taught in a number of CS programs alongside standard C/C++ courses. LV is visual and far more intuitive than any text-based programming constructs UNLESS you've been "brought up" to expect text.

[Val Brown]

QUOTE (bsvingen @ Feb 4 2009, 12:30 PM)

Java is not open source. It is proprietary and closed, but free (as in free beer). The difference between java and LV from a "high level commercial" point of view, is in fact price only. But there exist another programming environment, Matlab, that is general purpose in nature and much more expensive than LV, still it has a much larger user base. With Matlab it is also possible to make stand alone executables, yet extremely few use Matlab to make general purpose programs.

There is also a Matlab open source "clone" called Scilab. It even has a LabVIEW node that can be used. Everything is open source and free and supported by NI it seems. I tried it a few months back, and it seems to work just perfectly (if I only could find some real world use for it ).

I think that, again, you make one of my main points. What differentiates Matlab from LV is that Matlab is TEXT! So, yes, the text-based "crowd" really likes it and it is taught in a number of CS programs alongside standard C/C++ courses. LV is visual and far more intuitive than any text-based programming constructs UNLESS you've been "brought up" to expect text.

[Grampa_of_Oliva_n_Eden]

This discusion reminds me of the "Why would you want to waste all of your CPU on a mouse when can do the same thing with a keyboard?".

So I say let them talk, I'll go draw pictures.

Ben

[Grampa_of_Oliva_n_Eden]

This discusion reminds me of the "Why would you want to waste all of your CPU on a mouse when can do the same thing with a keyboard?".

So I say let them talk, I'll go draw pictures.

Ben

[Val Brown]

QUOTE (neBulus @ Feb 4 2009, 12:48 PM)

This discusion reminds me of the "Why would you want to waste all of your CPU on a mouse when can do the same thing with a keyboard?".

So I say let them talk, I'll go draw pictures.

Ben

...esp if the keyboard has a trackpad because it's on a laptop!

[bsvingen]

QUOTE (Val Brown @ Feb 4 2009, 09:41 PM)

I think that, again, you make one of my main points. What differentiates Matlab from LV is that Matlab is TEXT! So, yes, the text-based "crowd" really likes it and it is taught in a number of CS programs alongside standard C/C++ courses. LV is visual and far more intuitive than any text-based programming constructs UNLESS you've been "brought up" to expect text.

I think it is more to it than that. There is something called algorithms, and this is where LabVIEW falls bang to the floor. LV is good at expressing data flow, but terrible at expressing the algorithms operating on that data. FORTRAN is extremely good and incredible efficient at it, while C/C++ is more than adequate and extremely flexible. Matlab is also extremely good at it, but inefficient enough to be nothing more than a university tool. I mean, how would a general purpose matrix solver look in G? completely incomprehendable, that's how.

A side note. Downloaded that Scilab-LV thing along with Scilab. There is a new version from desember 2008, but it seems broken, giving a runtime error. Anyone else got it to work?

[jzoller]

QUOTE (bsvingen @ Feb 4 2009, 01:30 PM)

...

Java is not open source.

...

Well, http://www.sun.com/software/opensource/java/faq.jsp#b2' rel='nofollow' target="_blank">sort of.

As far as algorithms, I've never had much trouble making them comprehensible in LV, including building the usual data structures/methods and simple compilers and script engines. I do miss pointers sometimes... though I never thought I'd say that when I was first studying them!

Joe Z.

[Jim Kring]

QUOTE (Val Brown @ Feb 4 2009, 12:41 PM)

I think that, again, you make one of my main points. What differentiates Matlab from LV is that Matlab is TEXT! So, yes, the text-based "crowd" really likes it and it is taught in a number of CS programs alongside standard C/C++ courses. LV is visual and far more intuitive than any text-based programming constructs UNLESS you've been "brought up" to expect text.

Don't forget that text-based languages are inherently open, in the sense that you can use any editor to read and modify the sources.

[Val Brown]

QUOTE (Jim Kring @ Feb 4 2009, 04:11 PM)

Don't forget that text-based languages are inherently open, in the sense that you can use any editor to read and modify the sources.

Yes, of course, but isn't that also part of the problem? I mean you could even use card punch to implement text-based languages but aren't we sort of like a couple of decades past all of that? Or are we saying that we should reduce what we do to the lowest common denominator, ie a notepad compatible text editor?

[Phillip Brooks]

Any person with programming experience can laugh at this.

Only a LabVIEW programmer would laugh at this...

Jim's magical use of the word open is important. The upper image is "open". Practically any programmer can read and interpret it. It can be compiled and adapted to run on virtually any type of computing platform.

The lower image can only be created and executed with a specific programming language.

[PaulG.]

QUOTE (neBulus @ Feb 4 2009, 03:48 PM)

... I say let them talk, I'll go draw pictures.

Ben

:laugh: I've heard it more than once from non-LV programmers: "You LV guys do nothing but draw pictures all day". Usually joking, but sometimes with utter contempt.

[Gary Rubin]

Since bsvingen brought up Matlab and LabVIEW, I thought I'd add my two cents.

Lately, I've found that I've been quicker to open Matlab than LabVIEW for a lot of my tasks. I still prefer LabVIEW for anything that has to interface with hardware (whether NI or third-party). For other things I find Matlab much easier to deal with. This thread has caused me to try to take a step back and think about what has led me to that preference.

1) Data presentation: I find that Matlab's plotting capabilities are much stronger and easier to use than LabVIEW's.

2) Expandability/feature creep: Lately, I've been primarily writing code to assist me in performing data analysis. In those cases, my product is not the code or the GUI, but the analysis and conclusions I can generate using the code as a tool. For this reason, it can be very difficult to define a priori exactly what the code has to accomplish. My processing/code-development effort might sound something like this: "Show me A vs. Time, B vs. Time, and A vs. B. Hmm.... That's interesting - now what if I perform operation X on A, then plot A vs. C", etc. A text-based language like Matlab makes it very quick and easy to throw an extra operation in between two existing steps. Attempting to do the same thing quickly in LabVIEW tends to cause spaghetti.

3) Toolboxes, etc.: I occasionally do georeferencing of data to match it up with terrain or overhead pictures. Matlab has a Mapping Toolbox, LabVIEW does not. Matlab also has a large community of people who share their code. I have not yet found a Matlab forum or community that is as strong as LAVA in terms of answering questions or having the type of discussion we're having now, but there do seem to be a lot more people sharing their work (~9000 files in Matlab Central's file exchange vs. 74 in the CR here). A lot of that is probably cultural and is quite understandable - if LabVIEW is more heavily used in industry or by consultants/contractors, then of course people aren't going to be quite so willing to give away their work for free.

4) Backward compatibility: This is related to my previous item, and to the "openness" that others have discussed. Because I'm still using LabVIEW 7.1.1, I can't even open a lot of the files that people have posted here. At least with Matlab and other text-based languages, I can still look at the code.

Let the flames begin...

Gary

P.S. bsvingen, good to see you back here. Occasionally I've stumbled across our conversations about execution speed from a couple years ago and wondered if you'd disappeared.

[Grampa_of_Oliva_n_Eden]

QUOTE (PaulG. @ Feb 5 2009, 07:46 AM)

:laugh: I've heard it more than once from non-LV programmers: "You LV guys do nothing but draw pictures all day". Usually joking, but sometimes with utter contempt.

OK lets go back farther...

Imagine the discusion regarding using Roman Numerals vs the scheme we use now (arabic?). The old timers that are used to the Roman numerals would say

"

Why would I want to write all of those characters to (1000) when I could just write "M", besides only mathamaticians can read those silly codes. Not to mention the confusion over the signifgence of what those funny characters mean! With Roman numerals I can cut and paste( not applicable to stone tablets) an "M" from this number to another number and it always produces the same number.

"

Not so long ago maybe 25 years ago I was talking to a software type (I was still hardware at that time) and he asked me

"

Why are you trying to learn "C" when you can do everything you want using Fortran?

"

I have been at this computer stuff for 33 years now and (note analogy for Jim) and have observed that

"Riding the technology wave is like surfing, as long as you stay on the leading edge, you can ride it for years. Fall behind the edge and you could wipe-out or it will leave you behind."

The moment I fisrt saw a LV diagram I felt a sense of dejavu to the conversation with that software guy about "C" year prior. In my mind eye, LV is the leading edge of software development environments and I hope to ride it all of the way to the beach (retirement).

Ben

[Val Brown]

QUOTE (Phillip Brooks @ Feb 5 2009, 04:26 AM)

Any person with programming experience can laugh at this.

Only a LabVIEW programmer would laugh at this...

Jim's magical use of the word open is important. The upper image is "open". Practically any programmer can read and interpret it. It can be compiled and adapted to run on virtually any type of computing platform.

The lower image can only be created and executed with a specific programming language.

Perhaps, BUT -- and it's an incredibly large but (which anyone can laugh at) -- how long would it take a non-programmer to laugh at each one?

Now before this reverts to "noobs" vs "real programmers", it again makes my point. Everyone who says the top comic is "easier" to understand is simply well taught in text-based languaging of operational code.

And actually we don't DRAW pictures, we USE pictures (graphic images) to accomplish real-world tasks. Hey keypunch still works, as do TTYs...

QUOTE (Gary Rubin @ Feb 5 2009, 05:38 AM)

Since bsvingen brought up Matlab and LabVIEW, I thought I'd add my two cents.

Lately, I've found that I've been quicker to open Matlab than LabVIEW for a lot of my tasks. I still prefer LabVIEW for anything that has to interface with hardware (whether NI or third-party). For other things I find Matlab much easier to deal with. This thread has caused me to try to take a step back and think about what has led me to that preference.

1) Data presentation: I find that Matlab's plotting capabilities are much stronger and easier to use than LabVIEW's.

I find exactly the opposite, esp with the picture control toolkit.

QUOTE (Gary Rubin @ Feb 5 2009, 05:38 AM)

2) Expandability/feature creep: Lately, I've been primarily writing code to assist me in performing data analysis. In those cases, my product is not the code or the GUI, but the analysis and conclusions I can generate using the code as a tool. For this reason, it can be very difficult to define a priori exactly what the code has to accomplish. My processing/code-development effort might sound something like this: "Show me A vs. Time, B vs. Time, and A vs. B. Hmm.... That's interesting - now what if I perform operation X on A, then plot A vs. C", etc. A text-based language like Matlab makes it very quick and easy to throw an extra operation in between two existing steps. Attempting to do the same thing quickly in LabVIEW tends to cause spaghetti.

I find exactly the opposite here as well and a lot of my work involves "ad hoc" variations of my current code to add-in features, troubleshoot and prototype alternatives, etc. to my already novel visualization and analytic routines. It's difficult for me to imagine how that would go using Matlab, C/C++, etc.

QUOTE (Gary Rubin @ Feb 5 2009, 05:38 AM)

3) Toolboxes, etc.: I occasionally do georeferencing of data to match it up with terrain or overhead pictures. Matlab has a Mapping Toolbox, LabVIEW does not. Matlab also has a large community of people who share their code. I have not yet found a Matlab forum or community that is as strong as LAVA in terms of answering questions or having the type of discussion we're having now, but there do seem to be a lot more people sharing their work (~9000 files in Matlab Central's file exchange vs. 74 in the CR here). A lot of that is probably cultural and is quite understandable - if LabVIEW is more heavily used in industry or by consultants/contractors, then of course people aren't going to be quite so willing to give away their work for free.

It seems to me that LAVA does a fair amount of code sharing but, more importantly to me, it does an enormous amount of expertise sharing (your second point about LAVA) and that is a far, far more important resource to me personally and I suspect to most LAVA members. I don't need mapping capabilities but, if I did, I would look for some form of ActiveX component that could do the same. Something like what I've done to encapsulate WMP for my use and, hopefully, at some point in the future NI will do the more complete encapsulation that I've requested (esp maintaining the size of the visual image regardless of source when Pause and Play operations are toggled repeatedly).

QUOTE (Gary Rubin @ Feb 5 2009, 05:38 AM)

3)4) Backward compatibility: This is related to my previous item, and to the "openness" that others have discussed. Because I'm still using LabVIEW 7.1.1, I can't even open a lot of the files that people have posted here. At least with Matlab and other text-based languages, I can still look at the code.

I understand about not being able to "forward" visualize from an earlier version. I guess that's kind of like trying expect C++ classes to function exactly the same in an early release of SmallC or something like that. Yes, it would be nice if LV could forward visualize and leave a :question: as a marker when it didn't recognize a construct from a version of LV later than the one running; however, I expect that's a very difficult feature to implement. I don't have this issue because I'm on SSP and keep up with the most current versions pretty well and I find THAT process far, far smoother and easier than having to update an almost infinite variety of C/C++ libraries, COM objects, NET controls, Matlab scripts, etc, etc. One source (NI), one product containing its own dependencies that are completely versioned internally (LV and its toolkits) -- all of that greatly simplifies my life and adds most of the complexity and capability that I need but I also have a rather specialized situation in that I'm a single programmer, with essentially a single family of products.