Leaderboard

I'll still give you a chance to withdraw that comment. In my book the auto-tool helps someone that doesn't know what they need to do next (switch tools) and the QD helps those that know exactly what they want to do faster. Or are you just trolling? Ben

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

Well the OpenG pipe library has a System Exec equivalent that also returns besides the pipes for the stdIO and optionally stdErr the resulting task ID. And then another function which can be used to kill that task. Works like a charm for me for starting up command line tools that have no built in remote control to quit them. The OpenG Pipe library has not been released as a package but can be found here as a build OGP package.

Check my post (it's #3). But I didn't supply an argument for it. Felix

Nobody has mentioned the obvious feature... Data Flow By using graphical represenations of opeartions, typos* and syntax errors are eliminated. Memory management No need to check limit malloc and debug access violations. For those cases where the memory allocations are not obvious LV includes "Show Buffer Allocations" to let us SEE where the buffers are located. Ben * anyone that has read more than one of posts should understand why I really apprecaite the lack of syntax.

I also don't understand the auto-tool hate. Just diable it? But it is not better than the quick drop. Those who say otherwise are clearly just wrong. I'll throw in support for UI/panel "feel" gripes. The icon editor was a huge step in the right direction and I didn't criticize it in 2009 since it was new, but since it's still chock full of bugs in 2010, I feel laying into it is justified. It's a good idea not fully executed, and as a result poorly executed. I won't say it shouldn't have been released in the state it's in, because it is better than the old one, but it is slow and annoying to say the least. -m

I don't agree with you in the slightest but it depends on how you've come to habitually use your computer. I'm much better with the keyboard than the mouse .. if there was a way to drop and wire with the keyboard, I would

Hello JG Reading again this thread, I notice that this workaround have a lack. You'll lose the recording mechanism integrated in the facade.vi. if you never write "Data". This can be really annoying if you want to distribute your XControl. It won't behave as the user expect to. We really need a bug fix from NI Regards

RE: Speed - Darren recommends it - need more be said Well, I won't argue the above as I believe the DSC could do with a bit more polish too. But I think Shared Variables are a powerful addition to LabVIEW. The evolution of all these related products - DataSocket, Tags, NI Scan Engine, RSI, Alias IO, streaming, IO Servers, support for type-defs etc... has really impressed me. I looked forward to its continued growth.

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.

The wire. Felix