Jump to content

brent99

Members
  • Content Count

    36
  • Joined

  • Last visited

Community Reputation

0

About brent99

  • Rank
    More Active
  1. 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 wors
  2. 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.
  3. 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
  4. 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?
  5. 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?
  6. 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.
  7. 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.
  8. 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.
  9. 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 an
  10. Ha, you suckers that upgraded to 8.20, now what will you do while your coffee is brewing in the morning?
  11. 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
  12. 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
  13. 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 ve
  14. 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.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.