ShaunR

I can't walk and chew gum at the same time either

There are examples shipped with Labview. Hardware Input and Output\General

Well. A sticky at the top would dramatically reduce the "Why Can't I" PMs. And although they may have something to put in the general area (although haven't seen many newbies that don't post relevent to their problems), it might be a worthwile excersise to lock it for a short period to "Train" them and ease the workload on the mods for moving them. Just my 2 cents.

+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