Val Brown

QUOTE(tcplomp @ Nov 20 2007, 12:37 AM) Would that be the May 2007 set?

QUOTE(jpc @ Nov 16 2007, 02:53 PM) John: As far as I know, your colleague is correct: ie, this problem has persisted into v8.5. And so has the recommended work around, viz, only perform the open operation ONCE and then pass the reference around in shift registers...

QUOTE(clynch @ Nov 15 2007, 12:45 PM) Unfortunately bias and prejudice usually "points the way" instead of information. After all, if that weren't the case, we'd all be using Dworak keyboards instead of QWERTY.

QUOTE(Aristos Queue @ Nov 15 2007, 12:25 PM) Yes, that all makes sense but the current support for external code is somewhat lacking for anything other than simple ActiveX objects. I have a specific library that I would like to support but it will involve me writing all of the wrappers for the properties and methods because the DLL Import Wizard can't correctly interpret the code. I'm sure that the original developer of THAT code would be happy for me to send it off to NI so that a more convenient import process could be developed -- I had previously submitted several SRs in re: to this problem. It would be a real benefit to many (I'm sure) if this kind of extension could be implemented re: the DLL Import Wizard.

Of course it is the completely uninformed and rather parochial OPINION of that author that relegates LV to the "backburner".

QUOTE(PJM_labview @ Nov 14 2007, 06:22 PM) Was this in LV8.5? If so then, yes, I believe I have seen some similar corruption but in my case LV complained about he BD being corrupt and unable to be loaded -- even when it was!

QUOTE(JFM @ Nov 14 2007, 02:58 AM) Yes, that would definitely be "10,000 lawyers at the bottom of the ocean"...

How about a "Text-based Program" window like the Formula Node? This could allow for prior written code (perhaps only in C/C++ for ease of implementation in the beginning) to be dropped into a BD via "cut and paste" with the LV engine calling the appropriate link/compile process (hence restricting this, at least initially to the C/C++ base that underlies LV itself). IF this were possible -- and implemented -- it would instantly allow for the inclusion of all of THAT pre-existing code and that could be very appealing to folks coming from that background.

QUOTE(bbean @ Nov 6 2007, 06:55 PM) Hmmm, that's a bit like jumping from the frying pan into the fire....

QUOTE(Norm Kirchner @ Nov 1 2007, 12:45 PM) Now THIS sounds like a perfect use for LVOOP.

I'm posting here to bump this back to the top of the heap... Anyone else noticing problems with Vista and apps built in 8.5? One other factor that may be relevant here is that I'm using legacy dataog file functions. Any help/ideas would be appreciated.

QUOTE(Mache @ Oct 18 2007, 07:38 AM) Yes and no. IE was never "free" - it was bundled into the OS which had to be purchased. MS caught hell because they correctly saw that users just want an integrated experience, including internet, email, music management, etc. They don't want to HAVE TO make choices about funcamental services like internet access programs even though they also WANT to have choices available. A lot of time and resource was wasted by everyone to deal with that basic fight and, in the end, MS was right in essence. Firefox vs IE -- FWIW I use IE in Windows and Safari in Mac and I use them because they are the mainstream AND because I have companies to deal with if something goes wrong. Yes Microchip came along and introduced "free" in a market that already existed, otherwise they wouldn't have had ANY market penetration. Same with Java and it also probably wouldn't have gone anywhere EXCEPT that it was free. Email came free because of how the early internet evolved our of DARPA-net with its basic messaging. Again, a piggyback on established technology and "product" line. One of the other poster mentioned the role of older faculty -- who are not familiar with LV -- being a major impediment and I agree. The sentiment that: "If they're only going to get one programming course, let it be C" really needs to be shifted to "If they're only going to get one programmig course, let it be LV". And that will only come about as more and more of those senior faculty have experience with LV and what it brings to the educational experience.

QUOTE(jpdrolet @ Oct 17 2007, 09:31 AM) I believe that's G-Code as being a short reference for Gerber-Code. Does anyone know of any official stance from NI about the use of "G". Personally I don't like G++ but that's probably mostly because I don't like C++ (as a language). OK, there I said it. But it probably would be a bit of a "hook" to those in the C++ universe... Seems to me that there would be lots of possible G- combinations that could work well and take away the impression that LV is for Laboratories only/mostly. Even G-VIEW would be workable and would keep the acronym for VIEW available in the name.

QUOTE(LV Punk @ Oct 16 2007, 05:31 PM) Actually that isn't quite correct. I have worked in hospitals -- as a Department Head -- and my sister has run Research Hospital programs. My wife ran ORs. Yes, a big chunk of money is made on disposables but, the anesthesia IS a disposable, as our a number of surgical implements. "Use once, throw away" has become the standard for maintaining sanitation in many ORs.

QUOTE(eaolson @ Oct 16 2007, 03:38 PM) Well there it is, isn't it? You think free is about the right price and I expect to pay what something's is worth. Hmmm, perhaps that's why I'm not using JAVA.....<OK, that's a joke> I was watching Armageddon again last night and really loved the one line about how the shuttle was built by the lowest bidder. IME you get what you pay for. I'm really not interested in getting something for "free" when I'm using it to develop professional products to distribute to others. I don't know how comfortable I would have been with the surgeon performing my open heart (now 18 years older) had he said: "And we got the anesthesia and surgical instruments for free!"

QUOTE(jpdrolet @ Oct 16 2007, 01:03 PM) LV won't evern become completely transparent within XML nor will it ever release the patents. These twin pillars are what have maintained its interity as a product and environment over the years and that simply won't change. When you say LV-Lite I think you're really talking about cost again. My strong suspicion is that that won't happen either, esp not with Serial and TCP/UDP left in. Again the reasons you want it are the reasons that NI doesn't. Promoting parallelism is a very strong point and one that goes right into the "eye of the wind" for those not using LV -- they really can't "go there" but we can and pretty easily. Once THAT word gets out -- along with all of the other points about LV's overall utility -- THEN there will be an upswell in interest. There will ALSO be a huge backlash of folks who think it should be low-cost, open-source, available to all, etc, etc. None of those things are ever really going to happen IMO. And FWIW I don't think that they should.

QUOTE(Michael_Aivaliotis @ Oct 16 2007, 12:42 PM) Yes, and FWIW, I think the problem isn't that LV is a toy -- because it clearly isn't. The real "problem" is that it's too easy to learn. Yes, one can learn to use it BADLY -- we know that!. But the fact is that you CAN learn to use it fairly easily and there is a real perception/belief on the part of many "real" CS people that, "if it was hard for me, it should be difficult for you as well". The same attitude applies to medical residencies. They could be made to be far saner -- and that would save lives -- but the tradition continues of forcing residents to work extreme conditions at low pay. Obviously there are a lot of factors involved there but one that is shared IMO with the "problem" with LV is that it is simply too easy. And how many things do I NOT need to "know" to use LV well. I don't need to know VB, C/C++, C#, COM/DCOM, etc, etc. Knowing those things can -- or at least MAY -- be of help. But they simply aren't necessary. In that regard I remember when I was "invited" to pursue CS while in undergraduate school in 73. The head of the department wanted to enroll me in a course to learn BASIC and my reply was: "Why would I want to do that? It's not for Beginner's, it's not All Purpose, it's not Symbolic (except in the most primitive sense possible) but I do agree it contains a set of "Instruction Code(s)". So why would I want to learn something that is so poor at describing itself? Does that sound like a good tool to use to describe OTHER processes, events, information, etc?" I must admit that the conversation really feel apart at that point because he didn't even know that the word BASIC was an acronym -- I'm not even sure he knew that IBM was either... ;-) I don't really buy the cost issue. Yes, a Professional Devlopers package along with SSP (esp Premium level) is not cheap. But how much do you pay for MSDN, Visual Studio, VB, VC/C++, C# as well as the various additional components, 3rd party tools, etc that are involved in designed, building, testing, deploying and maintaining distribution projects/products? I think when you do a complete comparison -- and look at the overall cost/value ratio, it's at worse a toss-up. Given the learning curve and potential of LV itself though, it's a clear advantage to use LV primarily and only "branch out" as needed which, incidentally, seems to be far, far less important than in the past. The primary issue is identity/religion and this forms the basis of ALL of the programming wars (sounds of Darth Vader and Star Wars...). I know people who still swear by FORTRAN and PASCAL; but I know a lot of others who swear at those languages, or just walk away. Getting into schools is a great idea and is the real way this will happen as it will not only get students using LV early in their professional development curve, it will address the "it's not a real language" and "its' too easy to be any good" nonsense right up front, where it lives.

QUOTE(Aristos Queue @ Oct 15 2007, 10:01 AM) Actually I think that you might have meant to say that the movements were making you nauseated. If you were getting nauseous, then WE would have been getting ready to puke from the nausea that we experienced. As sick as you might feel I always find your posts to be interesting, informative, provocative (of creativity and innovation) and excellently written. Get well soon!!

QUOTE(Neville D @ Oct 12 2007, 02:57 PM) Yes, I was afraid I'd have to rebuild the tab.

I'm experiencing a rather odd problem. I have a tab control that I've inherited from an 8.2 successful, built application code base. The tabs are arranged along the top, to size to contents (of the labels) and each page holds indictors -- generally graphs -- that use calculations done in the event state machine on the BD. In 8.2 this code works fine. When I port this code over to 8.5, however, odd things begin to happen. For when thing the tabs size to over 8000 pixels tall! I can see no reason for this behavior and, since Panel Bounds is a read only property, I can't resize this Tab control programmatically. It's also not possible -- apparently! -- for to manually resize the tab control as it is on the FP. Here's the other curious bit. When I first migrate the VI holding this Tab control I get a numer of warnings about how the code can't find lyanlys.dll in the <LV>\resource folder but then, lo and behold!, it actually DOES find that resource and uses it. This then leads to a recompile of all of the lvlibs that relate to analysis/measurement functions. Now I can understand that the analysis/measurement funcitons may need to be recompiled, etc -- moving from 8.2 to 8.5 that would seem likely. But what I do NOT understand is how that is AT ALL related to the size of tab items on a tab control. Anyone have any ideas -- good or bad!!

QUOTE(Staffan @ Oct 12 2007, 06:11 AM) Are you (also) saying that your problem is resolved or is NOT resolved (yet)?

QUOTE(orko @ Sep 21 2007, 06:58 PM) Absolutely -- Congratulations!!! I have two daughters. One just turned 17, the other turns 21 in three weeks. The time really flies so enjoy every moment!

Nicely done. I for one am glad I've been programming with this "toy" instead of C/C++ for the last 9 or so years... ;-)

QUOTE(Aristos Queue @ Sep 18 2007, 11:12 AM) Yes. QUOTE(Aristos Queue @ Sep 18 2007, 11:12 AM) ...I realize that the vast majority of programs are a single developer who isn't worried about someone else on the team corrupting the data. But even in the single developer case, LabVIEW, as a test and measurement language, ought to be able to *certify* the correctness of code. The ability to identify all access points to a piece of data is critical in that code correctness. Yes, yes and yes.

QUOTE(jaegen @ Sep 17 2007, 03:22 PM) I understand that but, from a slightly different perspective, you make my point (implicit as it might have been in that last post but obvious in others). It's possible (likely?) that this feature may be removed -- seen as a bug and eliminated. If that happens what will happen to your code? Part of my trust in LV is that I KNOW what will and will not be there -- IF I stick with the fully documented features. I can and will -- and have! -- gotten support on them from NI when "something's changed" or "not working" and, as a developer, that reliability is of paramount importance. My days of chasing the "latest build of" some Unix-variant are LONG OVER, and I really don't want to get into THAT kind of stuff in re: to LV. I understand -- others have different perspective, different styles, different uses and different tolerances for doing that kind of dance -- and that's fine. But the question WAS asked and I've just given my perspective, FWIW.