brent99

Definitely a couple cool things in here. No doubt in my mind - that cleanup diagram is the runaway winner! I wish it would condense the wasted space in case statements though, and a "fix all vis" function would be fine for me (although I suspect someone will dummy up a tool to do that soon enough). I also had one of my large VIs choke on it, for no apparent reason. This particular VI needed nearly 4GB of memory to clean up. Oddly, other VIs of comparable size and complexity cleaned up in a matter of seconds. Go figure??? Gotta love that "wire through" feature too, easily one of the worst things in labview in my mind. Having to wire every freakin local variable through a case structure was the worst. The "cool but not necessarily something I'll ever use" awards go to the html feature that allows non-labview clientside interaction and possibly that wireless feature. Anyway, seems like everything upgraded ok and I cleaned up most of my legacy diagrams. Enough to make me want to renew my SSP.

QUOTE(PJM_labview @ Feb 25 2008, 06:42 PM) Or put in the context of my issue.... This would solve the "problem" if you could create an installer that installs via the web if the RT X.X runtime engine has not yet been installed!!!! Great idea.

QUOTE(REM1 @ Feb 25 2008, 11:47 AM) There are other languages besides english?? <sik> Well, there you go, 30MB for language support is a pretty big deal. And I think the browser plugin is somewhat unnecessary, based on my own personal experience having just installed that yesterday. The POINT is that you can't make "hello world" and distribute it to Joe Public (who doesn't have labview 99% of the time) under 10GB anymore, which is not good. And I use 10GB because MOST public email systems will not handle mail files larger than 10GB. In fact, most barely handle ones near 10GB if you are lucky enough to get an attachment to upload properly (works in hotmail, not much else). Looking at Labview as a great way to write simple programs, this is a problem. If you are looking at it for a full heavy weight corporate application, I don't think its such a problem but not everyone looks at labview that way (ducks).

QUOTE(Chris Davis @ Jan 21 2008, 01:37 PM) I saw that, and just assumed that Labview IS written in QT (at least as of v6.0 or so). No?

Yes, the "dead horse" posts are useful because its not just me, which was my question. The point isn't that there is an RTE, but that the RTE grew so dramatically from 7.0 to 8.0 with the main feature being a project manager. WTF? (Ok you could blame the new OO support, but then give us the ability to opt-out since its not a heavily used feature, I imagine) Although, speaking of large RTE, uhmm, isn't Labview compiled to machine language? Its NOT Java running byte code. Is it?

I apologize if I'm beating a dead horse here -- I'm not sure if and how often this has been brought up in the past -- but I'm kind of annoyed at how large the distribution file has become since Labview 7 because of the massive Labview 8 RTE. I used to be able to distribute a complex program at about 8MB or so. Now, even a simple program is taking like 50MB. Am I alone in this or do other people see this problem? You can email an 8MB program, but you have to serve up a 50MB program. It really limits distribution of a simple program to people who don't normally use Labview.

QUOTE(Aristos Queue @ Aug 7 2007, 11:14 AM) Instead of using a while loop that breaks out when the count > x or test=true, you use a for loop of x that can break out early if test = true. Slightly easier on the brain and apparently makes the vi code smaller.

I have a non-graphical COM object I'm trying to use. The object shows up as "creatable" when I try to select it but it only allows me to select one of two Interface files. I can't select the main object itself. When I select an interface file and put it to automation open, I get the "Can not create error 3004". Without creating, its a null reference. Is this a problem in supporting multiple interfaces with a COM object? I'm using 8.0.1. A working VB example refers to MYDevice, but Labview can only select IMYDevice.

I cheated -- used Vmware.

I have a fairly large project and building an exe can take a good 5 minutes or so. I'd be interested in reducing that time if possible. I tried putting a large section of my project into a library using the new project tree, but that did nothing in terms of compile times. I'm not really sure in what way that was useful at all, really. Not so long ago, I recall saving all my vis into an LLB and I believe I could pull from that without recompiling all of the VIs, leading to faster builds (although not sure about that). But these days, the "save all with options" stuff seems to be removed and the current LLB builder seems handicapped. Am I missing a good option here to place 98% of my VIs into a pre-built library, so I can link in 1 rebuilt vi and have the compiler be done quickly? Or is this just the state of LV right now that I got to watch my VIs get rebuilt over and over and over again?

Ha, you suckers that upgraded to 8.20, now what will you do while your coffee is brewing in the morning?

Ah: school on 1200 pounds a year. Nice if you can get it, I suppose. I think my books cost more than that. I think largely the point of NI training is corporate -- it is best for those who have software engineering experience but need to get up to speed in Labview as quickly as humanly possible because their feet are being held to the fire on a new Labview job. Most people with programming experience should be able to get up to speed on Labview with books and online resources that are readily available. I actually skipped the basics and went straight to the Intermediate classes when I was first dunked into Labview. And most of the intermediate stuff, if I recall correctly, is on an Application Builder level that would be outside the financial resources of most students anyway. Don't get me wrong -- your point on mass-propogation through inexpensive training is well-taken. Really, that's up to the NI marketing gurus on where they wish to focus their expansion efforts, and I'd bet that changes radically every year. Microsoft has always given their stuff away (well, practically) to academics in order to get young ones comfortable with the MS tools so they demand them in real jobs when they grow up. I don't know to what degree NI has looked into that strategy.

The doc says that they view the purpose of GOOP as encapuslation and inheritance, but much of the purpose of encapsulation is BECAUSE of pass-by-reference issues. I also found their argument for pass-by-value in standard G interesting, as they argue its to enforce the notion of parallalism which could have two independent processes referencing a variable in a non-standard order. Although, in practice, the problem I find more often is that I'll have globals in my code and have one part of the code update a state boolean global and another part of the code will come AFTER the update, read it, and Labview still hasn't been updated the global yet so it gets the wrong value anyway. This, I find, to be more insidious because I expect the update has occured already even when it hasn't. So these days, when I want to be sure an update has happened, I end up writing to it AND polling it to make sure the readback = the write. Dulp! Perhaps Labview is biting off a bit more than it should chew in GOOP. Incidentally, now that I'm writing about it, I really think this is something that should be fixed...I'm sure someone will say something about semaphores next. <g>

I think you've hit the nail on the head. I think the "pass by reference" issue really is one that should have received attention in the last couple years, because you get some real performance problems when you pass a large data structure between stages of a VI just to get it from VI #1 to VI #7. The workaround is probably to dump it in a global, but now you are really enforcing bad coding style. So hence, my reaction last week about NI managing to implement GOOP before "pass by reference" is a landmark in language devolution. Still, I think we can all see the continued march of G as a very serious development language and platform, rather than a simple prototyping tool.

Probably worth pointing out they added DYNAMIC calling of DLLs too. This is pretty huge, actually. DLLs currently lock up the front panel when you are in the DLL code, so a long DLL or a DLL that waits for another process needs to return control back to the VI or you end up with a frozen screen. Dynamic calling w/ callback should solve this far more efficiently.