ShaunR

There's a very limited "skypeSDK" on the NI website HERE which will demonstrate how to interface to skype.

Append your data to a file with the date as the file name (e.g 2010-01-10.csv). Then when the new day starts, a new file will be created.

Unfortunately its one I wrote for work (copyrights an' all that). But its not hard and you could probably knock up a straight forward one without bells and whistles (i.e compare vis in the project list with those in the directories) in about 1/2 an hour. Mine is quite slow, since it does a lot of checking (compares like the aforesaid and also loads up all vis and checks callers, callees, filepaths and compares duplicates etc) and gives me lists of vis on-disk but not in the project, in the project but in the wrong location, blah, blah. Oh. And I can choose to delete them

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.