Val Brown

QUOTE(tcplomp @ Nov 20 2007, 12:37 AM)

...To install it I need the May CDs of our SSP.

Would that be the May 2007 set?

QUOTE(jpc @ Nov 16 2007, 02:53 PM)

We are experiencing what we believe is a memory leak in Labview 7.1 when attempting to open and reopen an ODBC connection to a SQL database.

<snip>

My colleague who wrote code claims Labview 8.5 still has not fixed this problem.

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)

Yes it is his opinion, but it shared by many in the NXT world. Look at the other http://www.botmag.com/articles/10-31-07_NXT.shtml' target="_blank">link I listed, same message, different delivery.

I agree.

I thought NXT-G would naturally lead the NXT community towards LabVIEW. I don't think that so much anymore. Time will tell.

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)

I followed up on this. There are no plans to extend this feature beyond the small embedded-type platforms. The Call Library node exists for calling C code; that is considered to be both sufficient and more standard than an inline compilation of C code would be. Having support for the inline C would involve shipping a platform specific C compiler with every version of LabVIEW, and we don't have any interest in doing that. The embedded targets already have a C compiler built into them because that's how we get onto those specific targets, and the inline C node was originally conceived as inline assembler for efficient access to I/O registers on tiny platforms.

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)

Yes, I have seen this 2 or 3 times already. Like you, I was not able to reproduce it.

PJM

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)

What you want is Windows support of the "Inline C" structure?

http://zone.ni.com/reference/en-XX/help/37.../inline_c_node/

/J

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)

I've found this activex grid to be quite useful where the builtin mcl control in labview lacks:

http://www.devexpress.com/Downloads/ActiveX/XQuantumGrid/

If you can stomach using activeX.

Hmmm, that's a bit like jumping from the frying pan into the fire....

QUOTE(Norm Kirchner @ Nov 1 2007, 12:45 PM)

I would have to crack my head open and plug a RJ-45 into it to give you the proper link, as it has not been a discussion here on the forums. I needed to put it that way as I am not the original inventor of the concept. Scott Menjoulet is {resident LAVA lurker}.

To sum up - The original idea was that for each exported function that you wanted a program to have, you would have to create a specific 2-mode sub-vi that on the first itteration, it took the specific functions data type and created a user event that was stored in a USR within itself and also finish and output to a dynamic registration node in the host VI. Then from somewhere else, client remote PC, another VI, whatever would dynamically run that same 2-mode in the app instance of the host and in the second mode that it's run (not first itteration because already in memory and run once when the host started) it will fire the user event with the data passed to it in the dynamic call from the other app instance(or same, if you so choose).

so after that long summary, the original version did the same basic thing with the user events and firing them from a different app instance, but if you had 20 exported funcitons you would need 20 wires running into the register for dynamic events and 20 separate VI's and then 20 separate event cases regardless of what actually had to happen.

Using LVOOP, it becomes sexy and scaleable and flexible and all those other things that LVOOP provides.

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)

The thing about "free" is it works. If you want to become mainstream, that is the fastest and sure way to do it. The issue is "If you want to become mainstream".

Here are few classic cases of how free has proven itself.

1. IE Vs Netscape (IE is the most used Browser today)

2. Firefox Vs IE ( Firefox has mad great inroads against IE)

3. Microchip Vs Motorola - Among other factors, Microchip makes their IDE available free and Compiler is also free albeit without any optimization. You pay $500 for that. But for students, startups and hobbyists, it is most welcome and 10 years later Microchip PIC is the processor most used in world today. Mototorla, TI have caught on make their IDE free with some limits on code size.

4. Cell Phones. The market realy exploded when the cell phone was free with an year long contract. Before it was languishing. In south-east Asia to lure customers, they have incoming calls free!!

5. Email - Same thing

6. Java - the free thing helped it.

I believe in few years you will see...

Mache

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 think it is http://en.wikipedia.org/wiki/G-code' target="_blank">G-code

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)

You should be very uncomfortable!

I know as a fact that a significant amount of the equipment used in emergency and surgery rooms is "free" (pumps, instruments). The money is in the disposables. When equipment wears out or is broken by poor handling, the vendors give new equipment to keep their competitors out.

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)

For me? Free. Java is free and, if you want an IDE, both Netbeans and Eclipse are free. VB, VC++, VC# all have free Express versions which aren't very limited. (OK, I don't do much with any of these, so I'm not familiar with their limitations so much.)

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)

The JAVA Run-Time is 119MB and Internet users have to download updates regularly so I don't think that size is such a big issue.

I'd like to see :

• LabVIEW files formats to become an XML Open Standard so that everybody can make Edit/Display tools or even compilers.
  
• Release patents for graphical programming. There is no more reason to patent graphical programming than text programming. These slow growth and innovation.
  
• Make a LabVIEW Light version, without the heavy stuff for data acquisition. Keep Serial and TCP/UDP and some common protocols.
  
• Promote the parallel capabilities available for years and ready for multicore
  

That openness would keep Microsoft from embracing graphical programming and setting its own closed standards.

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)

I prefer at least to always remind everyone that the http://joule.ni.com/nidu/cds/view/p/id/861/lang/en' target="_blank">24MB run-time works just fine thank you.

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)

...I tried to play games or do some LV coding, but tracking the movements of the mouse cursor was making me nauseous.

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)

Maybe there is a label or caption that is placed hidden somewhere on the tab control and it resizes (auto-grows) to fit it.

Try turning auto-grow off?

Else just rebuild the tab control in 8.5 and delete the old one.

Neville.

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)

Hi,

The new behaviour on lvlib/folders is ok.

Using .lvlib was a way for me to include files in the application.

The new feature, "Perserve hierarchy" on the "Destinations"-page will solve this. This is something I have missed and asked for since the project was introduced.

The missing file problem/files at wrong location seems to be the same as Justin's.

/Staffan

Are you (also) saying that your problem is resolved or is NOT resolved (yet)?

QUOTE(orko @ Sep 21 2007, 06:58 PM)

CONGRATULATIONS!!

They are really a blessing, and make you look at life (and diaper bags, and car seats, and bodily fluids...) in a whole new way.

I'm just grateful she doesn't have your avatar's looks...

Hold her and enjoy her as much as you can now...before she can crawl away from ya' and starts liking *boys* (my daughter just turned 8 on Sept 18th)!

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)

...Creating a language where you must go through functions to access data, and the only direct access to data is in a limited, known set of functions, is a very high priority for code correctness in a massively parallel programming language (aka LabVIEW). The integrated development environment for such a language (aka LabVIEW's editor) needs to support shortcuts for users to create the accessor functions. But time is far better spent on such tools than on cutting holes in the language syntax that result in ambiguous code execution.

Yes.

QUOTE(Aristos Queue @ Sep 18 2007, 11:12 AM)

Yes, yes and yes.

QUOTE(jaegen @ Sep 17 2007, 03:22 PM)

I have to respectfully disagree ... if only because I've already used this trick in (soon to be) running code

Jaegen

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.