ShaunR

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.

I'm. infamous

Polymorphic VIs.

Version 3.0

Marginally And on a very particular edge case issue that no-one else seems particularly bothered by Indeed. And I could probably level the same argument at you, since I do not consider my work flow atypical. Lots of what-ifs in there . Projects haven't always existed and (quite often) I do a lot of editing without loading it. But that's just an old habit because projects haven't always been around and I'm just as comfortable with or without. Perhaps thats the reason I don't see many of the issues that others see since I'm less reliant on config dialogues, wizards and all the bells and whistles (sure I use them, but it's not necessary). User lib? Don't use it; I'm not a tool-writer. I don't have any problems re-using my re-usable stuff, never have. To me it's a bit of a storm in a tea-cup Thats quite funny. The last project I delivered was about 2000 VIs (excluding LV shipped). Only took about 1 minute to load and run in the dev environment (including the splash screen ) . And that could run a whole machine. Well. that (I would say) is a feature of Labview. If the project also did it. then I'd be a lot happier. Sure there is a practical way; load everything in the project. Requiring a programmer to write extra code to mitigate a behaviour is not fixing anything. Suggesting that classes (OOP?) is a valid method to do so is like me saying that I've fixed it by using C++ instead. I was specifically thinking about the fact it deletes the mutation history so being reliant on it not fool-proof. Never But it's a bit cheeky re-writing my comment. . I was not referring to typedefs at all. I was refering to LVOOP in it's entirety. From the other posters comments it just seems that the main usage that it's being put to is functional encapsulation. Of course it's not a "significant sample". Just surprising. I'm not prejudiced. I hate everybody I have seen how it can help me. Like I said before; Lists and collections. I've tried hard to see other benefits. But outside encapsulation I haven't found many that I can't realise much more quickly and easily in Delphi or C++ If it works for you, thats fine. It sounds like a variation on a theme (additions to existing......modification etc) That fits with what was saying before about only really getting re-use within or on variants of a project. No it couldn't. Once machine might have cameras, one might have a paint head another might have Marposs probes whilst the other has Reneshaw (you could argure that those can be abstracted, but you still have to write them in the first place). The only real common denominator is NI stuff. And in terms of hardware, we've moved away from them. Thats not to say there is no abstraction (check out the Transport" library in the CR). It's just we generally abstract abstract further up (remember the diamonds?)

Better there than here