hooovahh

I know these existed in 7.x, not sure about 6.x or 5.x which is when most of the OpenG stuff was made. Still it is possible it existed, but because it was a relatively new function, maybe the OpenG community didn't know of its full potential.

I'm using non OO based actors and I don't know the issue you are talking about. Are you you talking about when one actor will keep the application from closing? A global shutdown command that is a high priority user event takes care of that for me. One major reason I dislike the official Actor Framework is the reentrant-ness which forces you to other debugging techniques (setting break points in the VI saving, waiting for a clone to be made and stop, then being unable to remove that breakpoint while running) I thought about just Glue but it has taken on a life of its own now, and there's no changing it.

I almost didn't want to say because I was worried it would be stolen before it could be released. Still the likelihood of me being able to release it is small. Still I trademark it "Glued Framework", (Global User Event Driven) It is a user event driven framework, which is publisher subscriber based, where each actor subscribes to the user events that it needs. The publishing of the user events are in a write once read many (WORM) style global.

That was a fun little XNode and didn't take much time at all. More people should know about the neat features of Variant to Data when it comes to arrays and clusters.

I haven't seen this error but I have seen "Not enough memory to complete this operation". This error happened on a corrupted VI. I kept deleting things until the only thing open was this single VI with a blank block diagram but I still got the error. After playing around with it enough the error went away and I was able to compile. Copying the contents of the VI to a new one fixed it as well. Not sure if these are related.

What's in a name? Turns out alot. I have an Messenging like framework (it was made before Messenging was released), and it took me a long time to come up with a good name. I do think Messenging isn't a good fit, for a few reasons, but it does reflect what the software does which is better than some names. I'd say it should be changed, but I have no suggestions.

Are you referring to the Index Array under the VArray palette? I'd recommend using a Variant to Data converting the variant, into an array of variants, then you can use the native array functions to index the values out of the array.

QuickDrop is stored in the LabVIEW.INI but I tend to just blow these away periodically because I'll be developing plugins that then get in a limbo state. If these keys are in the INI it just reads the VI Description of the plugin VIs and sets their shortcut to what is in the description. Also as for synchronizing settings glyphs etc. We have large reuse library, and one package is for glyphs, and another is for "Templates" which has morphed into containing other settings too. During the package install it has a Post-Install VI that sets INI settings to how they should be. It also installs a few quick drop commands, and sets up the shortcuts for right handed developers. Generally we install the reuse library on a fresh machine from a base version, which includes all these packages.

Very neat, I think I may have met you guys at NI Week. Does this require or use the NI C code generator toolkit?

I had a white board that I would write bullet points on before leaving work. Even 18 hours later these would some times not make sense, but most of the time it was just enough of a reminder to jog my memory.

Yes OpenG also has their versions of getting data type of a variant. It bugged because in version 2011 the OpenG version was about 10 times faster than the NI version from the lvlib, but in 2012 and newer the NI version was about 10 times faster than the OpenG. At one point I had some goofy code that would know the version and pick the right one, but I convinced myself it wasn't worth it and to just go with the native (NI) solution whenever possible.

I agree with bookmarking, but to be honest I do this. The most common way for me to break a VI will be to double click white space on the BD to start a wire, then double click some other spot to end the wire. I've talked to some developers who didn't know you could do this, but then again how often do you want to start or stop a wire that isn't connected to anything.

There is an FTP palette in at least 2013 under Data Communication >> Protocols. There is also other FTP options like the internet toolkit, the real-time toolkit I think has FTP, and even command line options. All of these except the last should have examples in the Help >> Example finder.

Conditional indexing on For and While loops was added in LabVIEW 2012, which should be an issue because you are using...LabVIEW 2015...

I think I've mentioned this before, but our entire reuse from 2011 (and it is quite big) and all Windows based projects from 2011 to 2013 have has separate compiled code on every VI. Haven't seen an issue that was traced to this feature. We haven't used 2014 on any real projects yet.

I don't know where I fit in the spectrum of average LabVIEW users, but I would not be able to make the same application that I do today in 2013, in 6.1, without many extra weeks put into custom code for UI design, and work arounds and even then it wouldn't work as well. Drag and drop, events, property/invoke nodes that were added, VI server control, subpanels, user events, I mean have you ever tried to make a multicolumn listbox in 6.1 and have it be interactive? Sorting based on column clicking? Because I did once, and gave up when I was doing it with VB code and .Net to make tables. Not every version delivers a home run in terms of features, but many good tools come in 3 years, let alone 12. But I do understand the pain of upgrades, which is why I mentioned we don't upgrade unless we see a need. That being said since 2009 NI has done much better at maintaining version compatibility and feature set. I'd bet a large majority of 2009 projects could be opened in 2014 and work as is. There are probably a few tools that have been deprecated but I don't know what they would be. Also please don't think I'm attacking you. I simply think 6.x is too far. I'd say the majority of my code could be done in 2010 or 2009 without much trouble.

Thanks for the info, but this issue is not related to this package. No where in the spec file does "<Path>" appear or any "\" in respect to a path.

Put me down as another who has issues with this. So I make a VIPC with all the OpenG, internal, and some other packages for easy install for other developers. I started getting complaints that they couldn't install the VIPC with VIPM 2014. So when I got some time I installed each package one at a time until I found one that wouldn't install and the CCT was the culprit. It was a little weirder than that too. If a user double clicked the VIPC file that contained the CCT in 2014, then the Tools Network dialog would show up. Instead of the dialog asking about installing the VIPC. The same thing happened if I double clicked the 3.2.1-46.ogp file. The only way I could attempt to install it was to go to File >> Open Package File(s) and select the file. At this point I got the error saying there was a conflict. So I extracted the package, edited the spec file to not have any conflicts, then re-zipped it into a 3.2.2-46, and then I was able to install it by going to File >> Open again, but not if I double clicked the file. I don't mind attaching my version but I feel it would confuse people. Looking at the repository it looks like a version 3.2.2 was planned but never built. At the time of all of this confusion the developer had no packages previously installed.

Running applications from source is a bad idea in almost all cases. I highly suggest building EXEs. That being said it is more work to make an EXE. Especially if for some reason the builder craps out and you need to start over again. Locking down an application is critical if you are taking any kind of measurement so you know a developer wasn't fudging the numbers, or adding filtering and averaging to make it pass. I'm lucky enough that my company currently has a renewable license scheme, so I don't have to deal with your specific problem. LabVIEW 2011 is the oldest I currently go back to, but all active programs are developed in 2013 SP1. We generally wait until the SP1 release before using it on any programs. We don't usually upgrade a project to a newer version of LabVIEW, unless we see a need for it. It has added risk associated with upgrading, which is why we have some older programs running 2011. Having all versions you need is important because saving as 2011 in 2014 means you can now only open it in 2014, which could be a problem if all of your developers don't have the appropriate versions. 2011 is basically the oldest I'd want to go back to. 2010 didn't have static VI references, and a bunch of the other application control functions used often today. Here are some of the major benefits I see from going from 2011 to 2014. Conditional auto-indexing, and concatenating loop options. Icon Editor API for code generation. In 2011 there was some kind of API but starting in 2012 it had more exposed. Code complexity metrix using VI server New scripting functions, some with events Bookmark Manager, for keeping track of todo's or other tags in source Improvements in QuickDrop. Especially the auto-wire, which could be done in earlier versions. Clear specific error (OpenG has a function like this) More control over events with the events palette Event structure now has a trace window for debug Events can be lossy Much improved shipped examples Improved versions of the Actor Framework Mouse scroll event And what might be a big selling point, is the fact that the Professional and Full LabVIEW 2014 now includes PID Fuzzy Logic Toolkit, and Professional also includes Database Connectivity, Desktop Execution, Report Generation, Unit Test Framework, and the VI Analyzer Toolkit. EDIT: Oh and lots of FPGA and RT updates

Classic Shell to the rescue. I have Windows 8.1 boot to the desktop, with DisplayFusion and Classic Shell. It is like Windows 7 but better. I seriously have never seen the metro interface since installing these.

The blue-ish or green property or invoke nodes indicate scripting. Saying "Scripting" is not available in the run-time engine is an absolute that is a little fuzzy at times. Some functions are indeed only available at run-time. Like the Save Instrument invoke node. From a build EXE you don't have the ability to save a VI, so this function won't work in the run-time engine. To know if your function specifically is supported in the run-time you can open the context help, and over over the function. It will say if it is supported in the run-time engine and real-time. If this function works in the run-time engine, then you should have no worries using it. If you would like to enable scripting, so these functions can be used, other than copying the one you have, you can enable it by going to Tools >> Options. Then under VI Server check the box that is Show VI Scripting functions. Now your property and invoke nodes will have a lot more functions.

It's worth a read for sure, glad it was un-deleted. I still struggle to know when TestStand should be used, simply because for me the barrier to entry is higher. Oh you want to bring in another test tool? So developers that know some LabVIEW but have no TestStand experience will only be useful for developing pieces. And there is a development license cost, and run-time license cost? That on top of the fact that we have many already made tools for doing limits, test selection, reporting, manual control, etc. Don't get me wrong, I know TestStand's power, and in most testing applications, if all things were equal I would use TestStand, but unfortunately all things aren't equal, and being able to justify it to myself, and to management is difficult.

Awesome chain of discussion guys. Sorry OP if this is derailing the conversation but I think it still is relevant to the original question. Making and using polymorphic VIs is a major pain point for several reasons. And from a reuse stand point there isn't many other options. Replacing polymorphics with XNodes (if every officially supported) I think would help because you replace the 40+ instances with a custom scripted VI. No idea if it scales well. Jack you mentioned replacing polymorphic VIs with their instance. In my mind this is something that could be done quite easily with scripting for a while project. This could be a VI that is ran periodically, possibly as part of the Pre-Build VI that could help clean up the project. Did you ever make this scripting VI? Could you see sharing it if you ever did?

If that is the case I'd hope that there are some command line tools for imaging a disk, and I'd recommend just calling them. EDIT: Here is one such tool that I've never used. http://uranus.chrysocome.net/linux/rawwrite/

This is nice but I have a few questions. So I noticed there isn't any documentation when the Context help is open. In the past I've used the GetHelp Ability and read the VI description from a template. I would prefer that if a selection was chosen that was not in the range of items, that it would use the default data type for that data. So an empty string, or an empty array. This is more standard with the way NI does things too, like when indexing an array with a -1. I'd also like a more recognizable icon, but at the moment I don't know what I would want it to look like. Maybe it could resemble the Select primitive some how with a question mark, and lines that merge to the output terminal. Should all inputs be required? The Select input terminal is a U32, which is then converted to a I32. Could this input just be an I32? I realize this means you would allow negative numbers but again I'd prefer this, and to have the output be default if this is the case. Also what is the Select Mode options supposed to do?