Yair

The basic problem with both methods is that they're inherently manual. Mine has some advantage in that once you have the parsing code, adding a bunch of new classes is probably easier, but it's limited to what appears in the help. Jon's method is limited to the classes placed there by the user, but isn't limited to what NI placed in the help. I don't know of any way of getting all the class references automatically, but maybe someone else does.

There's an Application class method called Data Type Color which receives a variant and returns a U32. Note that this won't be relevant for class wires. Also, there should be a KB article on NI's site with an exact list of the colors.

One thing you can try to do to automate this is Open the LV help. Go to the property and method reference. Right click it and choose to print all of it. This will open a window with all the properties and methods as a long HTML page. You can right click this window to get the source of the HTML, which you can now save or you can print it to PDF or to Office. Now you can parse it. For each class, you get the inheritance list at the start. You can use this info to build a static tree, which you can then use to extract the data. Not particularly elegant, but it should probably work.

Impressive. Unfortunately, it doesn't quite fit the way I code (and I probably wouldn't want to use an unsupported Xnode in production code anyway).

Can you upload a video demonstrating the use of this Xnode? Screencast seems to be a popular site for doing these recordings.

Your chicken seems to be faulty. Please fill out requisition form 1240-B/8 to obtain a new one.

I don't think an 8.2 version will help you. Based on the description here, it looks like this plugs into the OOP version of the RGT, which was only released with 8.6 (and which I believe also relies on certain LVOOP features which weren't available in 8.2, so you couldn't backsave that even if the license allowed it, which it probably doesn't).

I believe BSD is a lot more convenient, because it doesn't require anything from the user. If memory serves, LGPL requires that you dynamically link to the code so that the end user can replace it (which is probably meaningless with this type of code, since at least parts of it are going to be modified by each user). If memory serves, that was the reason OpenG moved away from it and if the search here was reasonable, I could probably find the old discussion about it.

I agree that using a static ref is the best option. My description was simply that of the basic behavior of 2009.

How about just using Excel? I don't know if the .NET container supports it (although it probably does), but the ActiveX container supports it for sure. What you get is basically an Excel sheet inside your VI. The main issue with this is usually if you have different versions of Excel on different computers.

Here's the scenario I think you have: You have a VI which you only call dynamically (i.e. it's not in memory and you use the OVR primitive and wire a path into it). Its path is c:\my proj\VIs\dynVI.vi and the main VI is in c:\my proj). When you build you tell the app builder "this is a dynamic VI, always include it". In this case, LV will include the VI with all its dependencies and maintain the hierarchy, so the VI will be in c:\my exe\app.exe\c\my proj\VIs\dynVI.vi (the exact details may vary, I haven't studied this closely). If you place the subVI I showed in c:\my proj\VIs, it will always return the correct folder, even in the EXE.

I haven't looked through the other thread, and I haven't looked at how to do this recently, but one workaround you can use is calling an internal LV function to do the same resizing which is done using the cursor. You can see a simple example here. This comes with the usual warning about calling undocumented features, etc. If you're going to use this in an EXE, change the source of the DLL to "LabVIEW". This should tell LV to go the lvrt.dll file when running as an EXE.

But since those are worn on the outside, doesn't that mean your abstraction is leaking?

I simply meant the folder in which the code you call dynamically resides (or a parent folder. Basically just a base path which will allow you to build an absolute path to the VIs). Since dynamically called code is often plugins, that's the term I used. The point was that if you include the dynamic subVIs in the build, they will remain in the same place relative to that VI. This VI can be as simple as this:

Presumably, since the 8.x build option makes this work, it's simply a matter of you building the path in a way which is incompatible with the 2009 EXE structure. 8.x has all the files inside the EXE in a flat structure (except for those with duplicate names) and 9.x maintains the original hierarchy inside the EXE by using virtual folders. As suggested, using static references is the best solution for this, but if you do need to load the VIs dynamically, the easiest solution is probably to place a VI in the plugin folder which will return a path to that folder. Then, you will get the path correctly regardless of where the folder is.

First, I would recommend that you check if you can get this into OpenG. They already have a development process in place, as well as a distribution mechanism. Second, I would say that I would use it (at least if it's polished enough), but I'm not sure what "it" is exactly. Can you provide an example of potential components and how using such a component would work (e.g. I install the interface API and that gives me a palette with some common interface functionality and a wizard in the Tools menu for generating the VIs with the interface code for my clases). Third, I would say I would contribute, but unfortunately I doubt I would be able to hold up to that claim.

It's not a VI, but a primitive, which presumably means a lot as far as reentrancy configuration is concerned. FWIW, I'm not saying that they shouldn't be locked, just that it may not be as simple as going into a VI and changing it to be non-reentrant.

Cross post. It's considered polite to link to the other thread if you're cross posting to save people time.

You could just copy the LabVIEW.ini file from the previous version (I have to admit this gave me some trouble in the past, although I don't remember exactly what it was).

Presumably NI just calls the standard dialog window from the OS (e.g. MessageBox in Windows) and has little control over how it behaves.

I think the biggest annoyance was with the report generation toolkit. Many people made copies of its VIs in previous versions to do stuff it didn't do itself. In 8.6 NI changed the toolkit to be a class hierarchy, thus breaking all that code and requiring you to fix it. If you have such code, be aware of this. The same thing was done with the configuration file VIs in 2009, so if you modified those, you'll have to fix that too.

For things where you really want to make sure the user notices it, you're better off with a custom dialog which looks different (large, bold, red font tends to work).

You can also check out the recommendations I got here (although those are Ethernet ones, so you'll need a switch, etc.). I haven't done that project yet, so I have no results from that thread yet.

Actually, I'm pretty sure it was only in 8.6, so that excuse can't be used.

How's that going to work? The whole point of a SEQ is that all dequeues have no timeout, thus locking the access to the shared resource. Previewing doesn't do that (and it creates a copy of the data), so if you simply want a globally available piece of data, you can use a notifier (preview it to avoid losing old values) or even a global. Incidentally, in 2009 you can simply use a DVR instead of a SEQ.