Leaderboard

Self-indexing for loops. Beats ANY other language hands down as they don't have an equivalent.and have to put length checks all over the place and usually get it wrong .

I love LabVIEW and it lets me develop dependable code quicker than anyone thought possible for a decent price. I'm sorry NI, but this is for your own good. You'll thank me one day. LabVIEW is the Apple of programming languages. You are only allowed to do what NI thinks you are smart enough to do. A little less hand holding would be nice. (I swear I'm smart enough to not create race conditions) It took you 25 years to develop a pointer (DVR) to data? really?yes, i understand 1EQs have been around for some time, but they are kind of a hack[*]File dialog globally remembers last path[*]"lost" files in classes/libraries/xcontrols cannot be replaced with a file name that differs from the original lost file[*]ctrl+drag (the operation that "makes" space on the FP/BD) can't be disabled ever blow a hole in a case structure with 20 cases? datasocket/shared variables unpredictably gain/lose bugs every release cyclecauses me to go through weeks of DS/SV qualification testing every time we upgrade Network malfunctions/dropouts are highly visible to end users. #1 reason why my upper management doesn't think LabVIEW is a real programming language. would drop DS completely and go with SV, but i don't wanna buy DSC for security features that were included in DS going to raw TCP/IP communication as soon as i can. [*]LabVIEW Developer Suite does not include developer tools Express VIs don't count as developer toos Most webcasts/Virtural User Group presentations either cover basic/intermediate new user training or around something NI wants you to buy.Why can't they just be about becoming a better advanced programmer? Or how about an advanced application developer? You want to be a real advanced programming language, but you aren't giving your customers the tools to become advanced developers. The large application user group is a great example of this. gimme more! Most of us do not have computer science backgrounds. Anything you can do to bring in CS concepts and strategies would be appreciated. [*]Front Panel objects are outdated #2 reason why my upper management doesn't like LabVIEW (a.k.a it doesn't look cool) customizing objects is difficult and kludgy. because of this, i don't have time to make things look pretty. if you released a front panel control dev tool, the NI community would solve this issue for you Ok, now I'm done hatin...back to work.

It's okay if you were a little harsh, I'm in a good mood and didn't take it personally but if I was having a bad day who knows where I would have went. It's not often I compared to Apple. I don't like auto-tool, I can't give a reason that I don't, I can't say a programmer would be faster/slower with it, I've just not used it very often and am use to not having it, and that's a bad reason to not like something. It was mostly meant to be a joke with Asbo, who I know likes the auto tool and he posted it as a Best LabVIEW feature. I like having tools for programming, and productivity. I use a couple of quick launch keys, as well as a few others to help me do what I need faster. I've just never like auto-tool, but if NI enforced auto-tool with no option to turn it off I would adapt for sure. And just to get on a new topic, I hate how LabVIEW will not open a VI with the correct version of LabVIEW, it will simply open it with the last one that was opened. So if I open LabVIEW 8.0, then open LabVIEW 7.1, then double click a LabVIEW 8.0 VI it will give a dialog like "I know this VI was saved in 8.0 and I can tell that 8.0 is open but I tried opening it with 7.1 and I couldn't, try opening this VI with LabVIEW 8.0" Seriously NI? If you can tell what versions I have installed, and you can obviously tell what version the VI is, why would choose to open it in a version that is unsupported? I realize there may be more than one version that can open it, but why would you ever choose a version that can't open it?

I'm not an auto-tool fan either. It wires when I want to select and you have to select breakpoints and colour chooser anyway.... drives me mad. I'm a Tab and space-bar freak.

From the LabVIEW help Configuring for Multiple Thread Operation In a multithreaded operating system, you can make multiple calls to a DLL or shared library simultaneously. You can select the thread to execute the library call from the Thread section on the Function tab of the Call Library Function dialog box. The thread options are Run in UI thread and Run in any thread. If you select Run in UI thread, the Call Library Function Node switches from the thread the VI is currently executing in to the user interface thread. If you select Run in any thread, the Call Library Function Node continues in the currently executing thread. By default, all Call Library Function Nodes run in the user interface thread. Before you configure a Call Library Function Node to run in any thread, make sure that multiple threads can call the function simultaneously. In a shared library, code can be considered thread-safe when: * It does not store any global data, such as global variables, files on disk, and so on. * It does not access any hardware. In other words, the code does not contain register-level programming. * It does not make any calls to any functions, shared libraries, or drivers that are not thread safe. * It uses semaphores or mutexes to restrict access to global resources. * It is called by only one non-reentrant VI. Note All calls to LabVIEW-built shared libraries should specify Run in any thread. If you configure the Call Library Function Node using LabVIEW-built shared libraries and specify Run in UI thread, LabVIEW might hang and require you to restart. So, if the LabJack guys distribute a VI that calls their DLL with the Run in UI Thread checked, maybe they know it isn't thread safe. You could always try, but don't be surprised if there's a major crash And if it will run in any thread, then you might want to consider increasing the execution systems setting (I think that's the correct terminology) in LabVIEW to five, since each DLL call will consume a thread and with the default four threads per processor, one call might have to wait. Unless you have dual-core machine, then you already have 8 execution systems. Mark Shaun's faster than I am

What do you even mean by this? Who needs more than one mouse button? ...Me, my mouse is a 17 button with scroll wheel that also has a middle click (so I guess 18 buttons) To be fair I only use 5 of the buttons, but I don't see how not liking the auto tool means I like one mouse button. If anything it means I like using more than one mouse button for Shift + Right click.

Do you want the application that you have written to load when you double click the *.dat file, and directly start processing the clicked *.dat file? If this is what you want, please checkout the link http://labviewwiki.o...indows_Explorer /J

D'ya know what? I agree. Of course, some people seemed to think that's not necessarily a good thing. So, here you go. I did some one-handed bed coding and here's a basic mod of the transport library into LVOOP (2009). Some relevant comments: The transport example shows off the OOP advantage mainly through the inheritance property of OOP. This does not seem to be what your discussion was about, although the example does also reflect on your discussion. I didn't follow your API exactly. For example, your API leaked the TCP read mode enum out to the outer layer, where it's irrelevant. I didn't create a relevant equivalent in the API, since you didn't use it, but an accessor could be created for it and called before calling the Read VI. I only implemented TCP and UDP. I recreated the server and client examples (they appear under the classes in the project). You'll note that the inputs are now safer and easier to use (e.g. local port in the Open VI is now a U16 and does not mention BT). I changed the access scope on your VIs so I could use them without having to make a copy. The VIs themselves are also simpler (See the UDP Write VI, for instance. In your VI, it takes wires from all kinds of places. In my VI, it's cleaner and clearly labeled). Whenever you make a change (e.g. add a protocol), you have to recompile the code which is called by your various programs (assuming you reuse it) and you have no way of guaranteeing that you didn't break anything. With the classes version, you don't have to touch the existing classes. Code which is not recompiled does not to be verified again. I didn't like all the choices you made (such as using a string to represent either a port or a service), but I kept some of them because I was not planning on doing a whole refactoring. Also, you should note that my implementation is far from complete. Ideally, each class would also have more private data (such as which ports were used) and accessors and do things like input validation and some error handling, but I only created the most basic structure. To expand a bit on points 8 and 9 - You mentioned adding serial. That's a good example. What would happen if you now need to add serial, USB and custom-DLL-X to your protocols? You would have to touch all the existing VIs. You will be asked to recompile every single caller of the library (although with 2010 this is finally less of an issue). You would need to overload your string inputs to include even more meanings than they already do, etc. Contrast that with creating another child class and creating overrides for the relevant VIs - it becomes simpler. Also, with classes you can guarantee that no one will change the existing functionality by locking it with a password. For point 9, I would have a preferred a poly VI - one for service name and one for port. Internally, they can call a single utility VI to minimize code duplication, but for the API, you should have it as easy as possible. Currently, you place the burden of formatting the data correctly on the user of the library instead of constraining them where applicable. One example where your code will simply fail is if there's a service name which begins with a number. I have no idea if that's even possible, but if it is, your code will assume it's a port number and fail. This isn't actually an advantage of LVOOP (you could have created a poly VI using your library as well), but it would be easier in LVOOP. As you said, you could probably now compare the two by setting a series of tasks, such as adding more protocols or adding features, such as adding logging to every write and read. Actually, logging is a pretty good example. For you, adding logging is fairly simple - you add a path input to R/W VIs or you add it into the cluster. In the LVOOP code, adding an input to the R/W VIs would require touching all the classes, so I would probably do this by creating an accessor in the Transport class and simply calling it before the R/W VIs. This is one specific example where making a change to a class can be a bit more cumbersome, but it's probably worth it to avoid the other headaches. You actually have some advantage in this challenge in that you know and use the code whereas as I simply did some quick cowboy coding to adapt it, as opposed to planning the API beforehand. I also didn't do some needed stuff (see point 10). That said, the OOP version should still probably hold up, although I wouldn't unleash it as-is. Also, I doubt I will have more time to do actual coding, but I think this base is enough for some thought experiments. I should also point out that I'm more in your camp regarding the kinds of projects I work on, but that I generally agree more with Daklu in this thread. Transport with class.zip

Lava. Without it nothing else would have mattered for me. Yeah, it's not really an *official* Labview design feature, but it's the best learning/documentation resource that's available. The Blues that freely share their insights here are a big part of that.

Control references. They let us do in sub-VIs what previously had only been possible using attribute nodes. Instead of the BD of user interfaces being dominiated with attribute nodes, the diagrams can "look like what they do". Ben