crelf

It is now:

Some of us find those VIs really useful and use them directly in our code. This might not help you very much, but the new AAL course has some API design and implementation stuff in it. I haven't read that bit, but njhollenback wrote it, so I expect it's good.

Couldn't have said it better.

"I code in your general direction!"

Hillarious

Thanks for the quasi backup, but I'm not sure that whole industries have any particular attitude - as most engineers have a lot of exposure to UIs across a broad range of apps, they're exposed to intuative and not-so-intuative UIs. Just because it's easy to dump a handful of controls and indicators on a FP and call it done because it "Just Works Right", doesn't mean that you should. Sure, I'd agree that a functional program with a crappy UI is better than a non-functional program with a gorgeous UI, but we should be finding a balance - that's why UI design is important, irrespective of what industry you're designing/writing for. Industries may have an average way of doing things, but that doesn't mean that we can't (sometimes very slowly) make things more intuative. That said, keeping things the same is also a method of increasing intuativity (by association), and sometimes that makes more sense. Think of the UI changes from Windows 3.11 to Windows 95 - most of the gross UI updates were for the new users - but that made the existing users bitter, because it actually put them backwards. Actually it isn't better than nothing since you can easily end up with unreadable interfaces if you can't change the controls skin as well.. So you're saying that there's never a valid reason to change the background of a FP unless you can change the appearance of all the controls and indicators?! Don't remember saying that... You said that changing the background "isn't better than nothing... if you can't change the controls skin as well" I'm not completely familiar with a lot of other languages, but I don't think that you can define "all". You only get access to the attributes of a control that the developer of that control exposes to you. In this case, the attributes exposed in LabVIEW are less than other languages. In other languages, you don't get absolutely everything without getting into the very low level of the control itself, in which case you might as well write your own. Compare the LV1 palette with the LV 2009 palette. I'm not saying that there has been an explosion of changes in the last 20 years, but I think it's totally unfair to take the extremist view that nothing has changed. Please: credit where it's due. There's a difference between saying that not a lot has been done and insinuating that nothing has been done. If you've got ideas, get off your arse and suggest them over on the Ideas Exchange. And don't just say "we need newer controls" - list specific stuff that you want, and go into details of how you want it.

Is it a strawberry pancake?

So you're saying that there's never a valid reason to change the background of a FP unless you can change the appearance of all the controls and indicators?! I can't say I've ever heard that from someone at NI. I think you mean that *more* control properties are exposed, not *all*, right? I don't want to look like I'm itching for a fight, because I'm not, but I don't seem to be able to agree with anything you've written in this thread The controls palette underwent a pretty big change a few major versions ago - just take a look at the differences between the default and classic palettes. Anyway, I, for one, am glad that NI's spending the time on new controls and indicators (take a look at the new graphs available in LabVIEW 2009) and not spending that time on adding skin capabilities. Sure, it's a nice to have, but it's of very little value to me.

Right, and to get back on track, I'd suggest that you have different UIs for each "skin" that you want to show. That's the most elegant method that I can think of in LabVIEW. As was already mentioned, you can communicate with FP elements using VI Server or the like, so it's actually not that difficult to set up.

I don't think that's fair. Changing a background *is* close to skinning - it's a common component of skinning. Sure, it's not changing a whole theme, but it's definately better than nothing. Besides, in the industries that LabVIEW is used, I think that the ability to skin is pretty limited. A nice to have maybe, but I wouldn't suggest that the LabVIEW R&D spend too much time on it.

Yep - it's because LabVIEW has supported skinning for many versions It's a little known feature that kinda hidden - right click on the horizontal scroll bar of your FP, select "Properties" and you'll get a dialog that allows you to select from some predefined background or choose your own. I'm pretty sure you'd be able to access this property dynamically. Yep

Sure, but the use of shift registers in a sequence machine allows the data to flow between the panes. It's equivalent to the flat diagram you showed. Put it in a Software Desgin Document (SDD). I think having images in your code bloats the VIs. That said, if you don't follow a documented design process, then maybe it's the best you can do. I thought that the SDE was a good concept, but far too restrictive - it only really worked with one method of state machine, and it was one that I found limiting.

*sigh* for the last time - rep points are arbitrary and are awarded for whatever tickles the reader's fancy. It's about how much posts are appreciated by the community, irrespective of the topic. If it's for technical content, great. If it's for something amusing, great. If it's for a philisophical comment, great. If it's for a picture of a cat, great. Got it? Great.

Use virtual machines that are stored on a server - you can go select whichever combination of Windows/LabVIEW/TestStand that you need for testing.

Um, I know plenty of them. That's what a state transistion diagram is for, and we use them. I don't like that you're suggesting that the second implementation isn't dataflow - unless you've got some hidden references, globals, etc then it *is* dataflow - you're using shift registers. I *think* what you're argueing is that having your subVIs flat on a diagram is more intuative than a sequence machine (definition already exaplained by others in this thread), which I cautiously agree with. It makes little sense to use a state machine in this case, and I don't think there's much arguement there.

Intriuging. I must admit that I've never even tried to do that. Now I'm going to have to have a good think on why I would...

Ahhhhh - my misunderstanding. I agree.

I don't understand the loathing of the humble Queued Message Handler (QMH) state machine. Like every architectural pattern, it has it's uses and can be abused. We have a reuse library that encapsulates the QMHSM and it works great - as long as it's used appropriately. I can't see me suggesting that any pattern is inappropriate for all situations.

I think François was referring to The Emperor of the dark side from Star Wars:

We need more musicians and models in politics

That's better. You don't know my staff very well: there's little, if no chance of anyone around here listening to me, let alone being scarred

You know that awesome TestStand and LabVIEW programming you're currently enjoying? Consider it on hold: my car needs washing. How do you feel now?

The best advice I can give you is to either do the LabVIEW Intermediate courses, or get your hands on the course kits and know them. The exam is heavily based on the content of those courses.

Oh come on - your alien attack game is a great way to squirrel away a few minutes.