ShaunR

Heathen

Yep. That would do it. The key point being "ActiveX". You can try to make sure the open ref is only executed once (when the vi is started...ie outside any loops) and hope that the "stall" isn't from the get method.

Check to make sure you have "wired through" the shift register. You will normally see this behaviour if there is a case selector with an unwired tunnel. If there is a case which has no wire connecting the left shift register node to the right node, that case will insert a "NULL" reference.

It can be done (including your additional criteria) by saving the vi as a template (vit). You can then open it in edit mode (requirement for changing execution systems and priorities) modify the parms and then run it like this: However. This is probably not very helpful in the long term since the priority property is "Read Only" in the run-time engine so if you deploy it it will fail:frusty:

Private or public?

Does it currently auto-grow or do you have to make it grow manually?

You have to do a bit more than that to force LV to run certain vi's is certain threads. This is where "Threadconfig.vi" comes into its own. vi.lib\utility\sysinfo\threadconfig.vi It all gets a bit tricky from here on in as you need to manually manage what vi's are going into which execution systems and at what priorities. Most of what you need to know is in this thread (no pun intended...lol) Loop Timing & Execution difference

Didn't know Labview had a "Pizzle" . Amazing what the NI boys can do nowadays

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