ShaunR

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.. And there was me thinking that NI was promoting LV as a "general" programming language If you look at any other languages, skinning isn't actually a support of the language. It stems from the fact that all control properties are exposed and therfore modifyable (Think about the recent C++ poster trying to inherit from a boolean). The fact that LV R&D decide what you can and can't have access to limits this. If (for exampe) they exposed a booleans images properties (True, False, True>False, False>true) you could. LV user interface cpabilities has been pretty much unchaged since its inception. But it could be worse. Look at Labwindows....lol.

Amen I have known about background wallpaper, although not sure at what point it was introduced. And I would add to Crelfs elegant descitipion that if you use splitters you can also have different wallpapers for each pane by right clicking on the splitters left/right pane properties. But skninning goes way beyond that enabling choosing of control images, titlebar, borders......well anything visual thats represented by an image. Its more like a "I've got wind" emoticom

It'd be nice if LV supported skinning. Speaking of which.....Anyone know what the "IsSkinned" node is for?

You went way over my head at the title

Your mother is a hampster, and your father smells of elderberries?

When I was a kid, we used to make hydrogen, thermite and gunpowder. Kids are kind-a impoverished with health and safety nowadays

What about water rockets? all you need is a pepsi bottle and a bicycle pump

Yes. http://zone.ni.com/reference/en-XX/help/371361E-01/glang/property_node/

13 rep points awarded in 18 posts? Not a sniff of LV in sight.

I would disagree. The premis behind dataflow is that the change in value in one variable will cause a cascaded re-calculation in others. In a state machine, the change in value is dependent on "which" states and the "order" of the states that it passes through before another value is re-calculated. Whilst you may argue that "which" states is equivelent to the wired vis, with wired vis, the order is fixed by the wires and a value can only be modified by passing through a vi. The state machine releases you from the ordering restraint enabling branching backwards against dataflow. Well. If you had ever worked for a defence company or a large corperation then there is only 1 "pink" and it has a specific RGB value. I would proffer that most of that is just good engineering principles. Although I'm not sure how you "group by purpose" a case statement Not off-hand. I was brought up in a formal design environment so it became aparent to me very early on that LV was very appropriate for "top down" and "bottom up design". Those methodologies naturally yield "deep" hierarchical structure. I don't know python so can't really comment (9 languages is enough my for tiny brain ) Amen! Indeed. It was a rather a feeble example, since each state would only have 1 vi in it (but thats because of the hierarchal design). But it was more to demonstrate readablility. I did try (miserably by the sounds of it) to make that clear by saying "The readablilty issue is clear" . But the point was that a state machines readability suffers from the same issues as stacked sequences. What is your definition of dataflow? I don't think that just because shift registers are used makes it any more "dataflow" than using an "object" makes a program "object orientated".

If you use the "variant to flattened string" function, it has a type output array.

Its a good idea, but it requires special code in the users vi for everyvi. Passa Mak is a tranlsation tool that can be pointed to your projectand it will create spreadsheet format files for translations. These canbe dynamically loaded at run-time to change languages. Currently (fromthe users point of view) its a single vi that you plonk of the subdiagram and give it a translation name and it will dynamically changethe language of all controls and indicators you wish to translate. Theonly code you need to add is the vi and a text string (translationname) to one vi and it will change all that are loaded. This means itcan easily be retrofitted to existing code as well as new code. Indeed. The current implementation is very similar. Like I said..."It 'aint pretty" One issue you run into is that the vi you load the menu into needs to be visible which isn't very slick. You can get round that by putting it off screen but its all very messy and quite slow. I was kind-a hoping that there was a way to get the menu ref without resorting to file manipulation so everything could be in-place.

A state machine "should" (with a captial SH) be used to allow branching and "break" dataflow, not enforce it (dataflow does that implicitly). And you "SHould" only break dataflowas a last resort (it is after all LV biggest asset). A sequential statemachine is no different from a stacked sequence (in fact it is worse since it is more complicated). A procedural state machine not only flattens the hierarchy reducing abstraction and code re-use. It also hides functionality (making reading more difficult), is more difficult to debug and prone to transitional errors. Used sparingly, it is a powerful tool. Used excessively, well, you might as well write C. With the exception of message handlers, I've yet to come accross a state machine that requires more than 10 states. I have however seen many with 30+. (In fact, the last time I saw that many I made him re-write it in 5....lol) The readablilty issue is clear (as it applies to stacked sequences). Here is a dataflow implementation: Same thing written as a state machine:

I've just added menu support for Passa Mak. It works fine, but it 'aint pretty. The main reason being I can't find a way to get a top level vis menu reference. The menu seems to be the only FP functionality that doesn't have a reference thats exposed. Theres the vi menu ref (that only works within the current vi) and you can get it in an event structure (but can't programtically generate the event to execute the case). Anyone have any ideas?

The JKI State Machine Plugin........ The quickest way to turn a dataflow language into a procedural one

Engineers and scientists are generally really bad liers....a pre-requisit for politicians.

Naaah. I don't have those Now that IS worth a point.

The other downside is.....its activex

Nice. How much faster?

Saved for 8.0. It might be an idea to set your labview version in your profile so that people know what version you are using.

Ta very muchly I doubt it would be that soon. I'm off on holiday for quite a while soon:) And I've lost my momentum now I know I can't change my title at 500

So subtle, I never saw it before Indeed. I don't think a speech impedement qualifies as a "pun"

Hmmm. I've rewritten this post several times now, because there are so many aspects to what you are trying to acheive, I don't know where to start!. The first point that strikes me is that you are a victim of your own success. You have made yourself a "keyman" - an indispensible resource without whom projects cannot succeed. Whilst this is desirable from a job security point of view, when successful, you inevitably run out of resource (you). You obviously realise this and take the next logical decision to obtain more resource. so far so good. So you have identified some more resource.....students They will make the bits you need to make the projects. Sounds good, but is it? If it were a sub-contract software house or highly skilled, experienced engineering team, then yes, it would work since they know thier onoins and you can decide the granularity of the sub-components dependent on how much you want (or how much time you have) to be involved in the detail. Effectively, you would be recinding your "keyman" status and moving from a sole "deveoper" to a "team leader/manager". You could distribute small functions right up to complete applications dependent on your loading all under the watchful eye of your experience. and guide the project through to completion. But you have students (lots of 'ology' students at that, by the sounds of it). Inexperienced, un-trained, possibly un-receptive but none-the less cheap In addition to deveoping the projects, you will also have to teach, correct and probably re-write a whole shedload of code adding to your loading rather than alleviating it. Effectively you are still the "keyman". You have relinquished a bit of the boring stuff that would take you 1 day, in exchange for using resource that will use (say) 5 days of training, 2 days of correcting and a further day to write it the way it should have been Sure in 3 months time, they might (if thay stick at it) actually be contributing usefully to your project, but you didn't have enough time for one day to begin with. So is it a hopeless cause? Should we never train anyone because its always easier to do it ourselves? Not even close! We have access to resource And we can always use resource We just have to be intelligent about where we get it and how we use it........even if it means losing our "keyman" status". It sounds to me like you are making the transition from deveoper to manager (whether you like it or not), but can't quite let go. I can understand why, because you are the only expertise and a student is never going to be able to do what you do in the limited time available. And although this maybe true, maybe its not necessarily the coding you need to offload first, but the training. A few, cherry picked individuals, the chosen few (we used to call them "Prefects" at school) with an aptitude and eagerness for programming that can impart thier knowledge to lesser mortals and answer the inevitable time wasting questions so you don't have to. It means your time is well spent in training (they want to learn and are pretty good at it) and you can offload more and more of your key skills (well, always keep one or two, eh? ) whilst still delivering projects in the interim. If I'm barking up the wrong tree, I'm sure you'll let me know. I have a few further ideas if its worth persuing this direction.

What pun?

If you click on the "Highlight Execution" button you will see how Labview is executing your code. When the data reaches your case statement, you will see which case is executed when the boolean is in one position or the other.