ShaunR

+1 But how newbie does a newbie have to be? 10, 100, 500 posts?

Sorry Peeps. Couldn't post these in a PM so ignore me as I post them here for Cat. As Promised Cat.

Well. The Alpha thread (see what I did there ) doesn't discuss ideas, it preaches one persons view. I think we all have small minds before lunch when the blood sugar is low

Still none the wiser then...lol The correct translation is "Great minds discuss ideas ; Average minds discuss events ; Small minds discuss people."

Yes. There is a very easy way to do what you want. But not in the way you want to do it. Your array would be short right? (By short I'm thinking less than 2000 lines!) Just load all lines of the file using the "ReadLinesFromFile.vi" (-1 as the lines argument will read all lines regardless of file size) or "ReadFromSpreadsheetFile.vi" (the output of this vi is already an array type and also reads all lines regardless of size) to an array and let the user index through it. If you give him a back button (decrement) then he will also be able to go backwards (never say never...users are illogical creatures) with little effort on your part. Labview does this sort of thing much better than C/C++ since you don't have to declare array sizes before you start and arrays are self re-allocating so you don't have to manage the re-allocation (as you would have to in C). You also don't have to worry about overrunning the end of the array. GPFs are rare in LV Should take you 2 mins (including waiting for LV to load ) KISS!

I'm probably missing something huge here. But the beginning of an array is index(0) and the end is index(length-1). This is true if you add, delete or insert. The next item in the list is current index+1 and you just maintain an index to the current place in the list/array. No iteration, uses LV primitives but suffers from re-allocation penalties.

I'm not after anything, except a pay rise.lol

An array is a poor replacement for a linked list. A linked list is atomic and not contiguous in memory (hence the next-node pointer refs) and therefore doesn't suffer from memory re-allocation penalties when inserting, deleting or appending. You simply allocate the node and update the appropriate next-node pointer values. (The downside to this is of course fragmented memory). The main advantage of linked lists is that the operation time for insertion, append and deletion is consistent, which is not the case when array re-allocation occurs, since the re-allocation time is variable dependent on the array size. You can think of an array as a special (limited) case of a linked list where the list is of a fixed length and the pointer is the previous-node pointer+1. This case will perform the same as a linked list, but as soon as you insert, delete or append past the array length you will again get re-allocation penalties. I avoid linked lists like the plague in LV since I haven't come accross an effecient way of implementing them because the whole point of labview is that you don't have to worry about pointers . Perhaps a better way might be to write a dll (API) that manipulates your list. This may yield better results although you have other overheads but at least they will be consistent. Of course. this is only applicable if performance is the attractive quality of your linked list. If performance isn't an issue then just use a standard array and use the standard LV prototypes to insert, delete and append.

I've been using a parser for quite some time to create typedefs. It doesn't pars C/C++ header files since it was designed to pars excel created text files for high channel count digital and analogue IO. The short answer is yes you can automagically create typedefs (they must not be in memory when you update them) and you don't need to use scripting. Here is a snippet that shows updating of the typdef.

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