ShaunR

"Create Sub-vi" function. Saves hours if time when prototyping by allowing hierarchy realisation, easy modularisation and, of course, cleaning up diagrams. All in one step . Imagine what you would have to go through if you wanted to replace some code with a sub-vi if we didn't have it

Of course It's only UDP that doesn't so its 75% which I would count as the vast majority. I could have left it out completely and probably 1 in 50 programmers wouldn't have noticed. A leak means something different to me. I don't consider a NO OP a leak. Detecting whether there are any a-Z chars will fix that and it will work as intended. It's a trivial point. The port number change is the sacrifice I was talking about. You have sacrificed the user having to write more code to deal with it (as you have done in the example) for your preference for strict typing and partitioning.. That's a design decision.. But they didn't create the "Variant" type for nothing and I use strings like variants. That's not the reason. But good effort. The main reason is that a serial interface cannot be configured just by a single parameter as all the others can (a port or a service name). It takes many more parameters to make anything useful. Therefore it would have considerably complicated the users interface to the API in that he would no longer have to supply a single string but things like baud rate, term char, parity etc just for that one interface. It is much more appropriate to add that to a layer up, which is outside the scope of the current API implementation. Well. No-one has a crystal ball. You code to the requirements and try to mitigate where you can (usually based on experience). Anything else is just blowing in the wind.

I'm probably the only one that suffers from this, but...... Millions (OK slight exaggeration ) of activation codes for Dev Suites that assume you have internet and is therefore painless.

I neither like nor dislike. I don't really use it much since I tend to get one control just how I like it then copy it. What I do love though is that you can select a load of controls and make them exactly the same size at the click of a button.

They've just seen NIs invoice for Labview and all the tools without ans SSP

You've always been able to change font settings on multiple widgets

Post it here when you've written it an I'll give you a rep point

Shame. The problem is you don't have access to the command window reference so you can't even send it a Ctr-C, exit or terminate it directly. You could do it if you invoked a command prompt using api calls though.. And you could probably do it with a batch file or script. But none of that is portable.

Do you have to use Exec? Is multi-platform a must?

I would say (tentatively) no. It says "Because of this Add, Go, and Get must be called from the same thread" If you set the nodes to any thread you cannot gurantee that that won't happen since you don't know (from call to call) what will run in what thread. So Add might be in one, while Get might be in another depending on what labview feels like doing.

Indeed. Almost good enough for the LV help (as was stated)

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.

The difference is whether the DLL is "Thread Safe" or not. Orange means it runs in a single thread (the UI Thread and there is only 1). Nicotine coloured and it can be run in any thread that LV decides it wants too. It's best to use the UI thread if you are not sure. Side effects can be anything from crashes, strange behaviour, or erroneous calculation errors under certain conditions.

If you mean you want it to remember a fixed location. then you will have to either save the path somewhere (and load it when tha app starts), hard-wire a path into the file open, or save a control as a default value (right click on control then select "Data operations>>Make Current Value Default").. The reason it is asking you is because you have not specified a path into the file open (bear in mind that controls are reset to defaults when you open a vI or exe for the first time).

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 .

Tough call. Are thay all programmers? What languages?

Do you reckon this is going to be longer than the "Like" thread Everyone loves a good moan +1 for any user interface stuff

Great stuff. Lets see if Daklu is prepared to expand a little on it now you've shown the way I know You never know. Maybe I'll get my arse kicked and version 2 will be a class with you named as a major contributor The discussion was originally going to be much broader. But we got bogged down on a specific facet. The mode is relevant since the CRLF and buffered are very useful and vastly affect the behaviour. But for the purpose of this discussion it's irrelevant.. OK. They are 2 of the most popular. Yup. They work fine. Yup. Naturally. And some are just wrappers around my VI's I, of course have to make a decision. Do I put certain "messy" ones in a sub-vi just to make the diagram cleaner or not (maybe I should have). You don't have that decision, since you have to create a new VI anyway. Good point. What would you have done instead? Of course. I'm not expecting a complete re-factor. In fact. It's probably to our advantage that there is only a partial re-factor since it mimics a seat-of-yer pants project. That way, as the new design evolves we will be able to see what issues come up, and what decisions we make to overcome them and, indeed,, what sacrifices we make (you have already made 1 ). Serial was mentioned for a very good reason. Can you think of why it isn't included? After all. It covers most other bases. Yup. I was a bit lazy on that. I could have checked a bit harder. We'll call that a bug OK. I won't comment on your examples just now. Let's wait and see if Daklu is prepared to put some effort in. Indeed. I probably do know a little bit more since I've been through the design from start to finish. However. It was only 2 days from cigarette packet to release candidate so probably not much more. The only difficulty was UDP, everything else is pretty much a wrapper around in-built LV functions.

Granted. It is a difficult time of year. The new year would be fine when things are less hectic. The goal? To to highlight the advantages and disadvantages of one paradigm over the other with a real-world practical example instead of esoteric rhetoric. Your Father may be bigger than my Father. Let's get the tape measure out This I don't understand. You should always have a spec (otherwise how do you know what to create?). It's not fixed (what about adding serial?), only the interface is fixed (which you should understand since you are creating re-use libraries). In fact I chose it because it is particularly suitable for classes and IS a re-use component. It is very simple, well defined, obviously possible (since it already exists) and if it takes you more than a day, I'd be very surprised.. You talked previously about HW abstraction. Well here it is. You talk about re-use; It's used in Dispatcher and OPP Push File. It ticks all the boxes that you say OOP is good at, so I think it would be a good candidate for comparison. At the end, your lapdog thingy should work over TCPIP, UDP, IR and bluetooth as well. Wouldn't that be nice? If you think OOP is just for changing requirements. then you have clearly not understood it.

Ooooh. Almost forgot. Re-entrant VI's and the cool improvements to them over time (cloning, place inside self etc.)

Especially as you used to be able to change probe properties and resize the controls (like being able to view strings as hex). Or maybe I dreamt that

Well. I think from that little lot that it's pretty obvious that we've reached an impasse on that topic and perhaps it's time to expand the scope of the thread so at least it has some technical content again. But I will finish off off by drawing your attention to the LV help because it was obviously something you were not aware off. So. OOP is great. It's fixes all the ills in the world. It increases re-use so you only need 1 program to do anything anyone will ever want. So might I make a practical suggestion? There is a very simple library in the the Code Repository that would be very easy to convert to OOP and actually (I think) is ideally suited to it (we don't want anything too hard eh? ). Why not re-write it OOP stylee and we can use it as a basis for comparison between OOP and "Traditional" labview? Then we can plug it in to the other things in the CR that also use it and see what (if any) issues we come across in integration. Does that sound like something you can commit to?

Indeed. Sorry. Couldn't resist I could never figure out why people went for these crazy colour schemes. Then I worked for a defence contractor where there was a specification for software user interface colours. When I pointed out that it was a colour defined for "Cockpit" software because of the way colours were perceived through tinted visors and that VDU operators are unlikely to be using the visors. They said "Oh yeah" and carried on regardless

I'm not a fan of the Image type for the vision stuff either. I keep getting caught out even though I know how it works. A lot of vision stuff I do requires acquiring and image then creating various masks and applying them (often one after the other or in various combinations). The UI though, normally requires showing of original images and the results of the various stages of mask applications therefore you end up copying everywhere so as not to overwrite the originals or the intermediate results of a mask. It gets very messy But my pet hate is that you cannot wire a VISA refnum to an event case like you can with DAQmx. But more generally, the "probe window" introduced with LV2009.