ShaunR

Is this more the answer your expecting?

If you don'y mind using windows API calls, you can also call "ShellExecute" which has a couple of minor advantages over systemexec.

Touché ...lol

Indeed. I also came across another problem in that the save function isn't available in the RTE. so its back to the drawing board

Ummm. Thats not a vi though

Or this?

Well. Perhaps my comment was a bit harsh considering the newness of the site. I wasn't expecting that should I post that my suggestions being taken up though, just that I would only consider it a worthwile excercise (of effort on my behalf) if I saw a definitive criteria behind it (like the top 1, 2 or 10 are always implemented). That was the only point I was trying to make.

A different approach just to show theres more than one way to skin a cat ferret

Indeed. But I didn't say there is never a valid reason not to change the background (visually impaired users is an example where you might for example). But for most applications you can change the colour and don't need images. I can define "All" All properties and methods that are available at design time. The big difference is that most other languages come with full source for controls so if it doesn't quite do what you want then you can modify it or expose hidden properties....unlike LV. It'd be nice to be able to write our own Xcontrols are the poor cousin of native controls. I'd love a statusbar control with default panels for time etc. LV1 was MAC only. So it pretty much looked like Labwindows. I came in at LV2.1 (which was windows) and theres been little change since then in terms of UI but there have been huge leaps in functionality (most of) which I am thankful for. Perhaps if NI R&D always took the top 10 and implemented it I might. But I've seen no correlation between the Idea exchange and implementations. I'm sure they do read it, but I would imagine only those that are on the time-line are actually implemented so its probably more to do with your request just happens to coincide with a feature that was to be implemented. I hope I'm wrong though and would love to hear about requests that were taken on board. I use LV with what it has and if it doesn't have or do what I need, I use something else. And (by the way) I actually said "it would be nice" if it supported skinning. Presumably that will only work at design time. Nice little tool for branding though.

LGAS

Don't remember saying that, but then again I've never written an app that has a bitmap background. Ours tend to be solid black. But I've written loads in other languages that do and am just aware of the pitfalls. In fact, if its visually intensive, I wouldn't do it in LV in the first place. Why not all? Let me decide what is appropriate for my application. Nothing new there then I wouldn't say putting a few 3d borders was a major change. And even if you do, thats once in 20+ years and it still "looks" like LV. Aha. Something we agree on. Nice to have! The new graphs I can live without and have been for ages. Well. For me yes. You can change most of the bitmaps at design time as it stands (well booleans at least). But skinning is meant to allow a user to choose a visually appealing interface so it really needs to be at run-time. As for custom controls, try changing a cluster

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?