Yair

I haven't done anything like this, but Googling "programmatically install font" brings up some results. You can configure your installer to run a small batch file at the end which will do this.

Here are two options: Try doing a search on NI's site. Open a support request with NI. Reinstall LV (which they'll probably tell you to do anyway if you do #2).

Great. Thanks. Now I just have to get used to working with the unread list again. I'll keep an eye on it occasionally for a while, but I assume if they say it was fixed, it was fixed and we should no longer see this.

The snapshot itself is unhelpful. You should start by scrolling down to see the description of the error and then by expanding the details section (click on the triangle). Those should probably at least point you to the source of the problem. If you don't know what the problem is, you can try doing a search on the details you get to see if others had this problem before.

Since you have the OpenG VIs, you can have a look at the variant config VIs. The one which reads a cluster from the file builds a variant cluster based on the input cluster and you can then convert that variant to your data type. As you point out, this can be somewhat complicated. You should note that it also uses type descriptors which have been changed in LV 8.x and have been made private, so going forward this isn't necessarily a very good idea if you plan on upgrading. If you are thinking of upgrading, you could look at MGI's read-write anything VIs, which do a similar action, but use VIs which are shipped with LV in 8.x.

Note that this actually breaks in 2009 EXEs, because of the new EXE-as-ZIP scheme - the folders which are inside the EXE are recognized as actual folders and so the stripping stops while still inside the EXE. The function Shaun pointed to works around this.

I'm not sure how to describe the general problem, but I would say that this isn't a complex use case, rather one which is likely to be encountered on occasion. The rest of the mutation code seems to work fine and has some great advantages (such as correctly mutating the data when you rename a control, which I view as basically the same kind of change), although I admit to having some discomfort at not being able to supervise or override it easily. But surely that would mean that you end up with spaghetti code!

You can deal with the alignment problems by changing the format to a 1D array of clusters, where each element in the cluster is a column. The main problem with this is detecting which row received the event. I would suggest using a value change event and comparing the NewVal and OldVal terminals, like this: (inside is a cluster to array primitive).

I never did anything like this, but here are some thoughts: Keep in mind that whatever you do, the compiled LV code will be executed by the LV RTE and will be probably be loaded as a separate process (although I have no experience with that, so I'm not sure about the last part). VIs in DLLs can keep their front panel. If you want to embed the VI window inside the PARENT window, you can use the reparenting functions in the Win32 API (SetParent). If you set the window not to have a title bar, it will look as if it's "inside" the PARENT window. This might have some issues. You can enable the web server in the LV app, place a browser control in PARENT and use the remote front panel feature to connect to a running app. This may also have some issues, as well as some license considerations. LV 2009 can compile .NET interop assemblies. I never tried it, so I don't know what it looks like in practice.

Your concerns about having multiple classes with the same GUID are legitimate. Daklu's suggestion of throwing an error in such a case and adding an explicit "rename and preserve history" option sound reasonable. This will mean that people who copy and rename the file outside of LV will get an error. Assuming you got grades which were less than A in your CS courses, did you defend the work under the shield of the poetic license argument? Also, personally, I'm more of a code cartoonist than a code poet, and as such, should be exempt from such stringent requirements.

It's not, at least in 2010. I didn't bother looking for where it is. Anyway, this seems to be the binary hacking method I refered to earlier. The tag methods should be accessible either by installing the scripting API from NI or adding the correct superprivatekey (or both, for all I know). That's all I have on my machine and I see them.

And I would be one of them. I didn't say the GUID should have anything to do with the class name. Ideally, it should be something which the user does not see. I agree that there are problems with the GUID suggestion, but I'm not sure the ones you mentioned are necessarily the biggest ones. Here are some attempts at addressing those concerns. First, any copy operation on the class creates a full copy, GUID and all. One option of handling the GUID issue is that when you next open the class, it recognizes that its current name is different from its last name and asks you "do you want to change the GUID?". A good solution? I don't know. It will likely confuse some users. Another potential mechanism is adding a "change GUID" button to the properties dialog. The fill-in-a-missing-class scenario? Probably not a problem, if the class is missing, so is its mutation history. I don't know. Both clarity and data preservation are important, or I wouldn't be running into this issue. All I know is that there is a real requirement here - I want to be able to rename a class and still maintain its history. Is there a satisfactory solution? I don't know. Is the current one the best that can be done? Don't know that either. I'm sure you gave this way more thought, but the problem remains.

This was precisely the reason I brought up this point yesterday - people are not aware of this issue and it's very easy to get bitten. The problem is that this declaration is done by name. There are legitimate reasons for wanting to change a class name without wanting to lose the history, so it would have been nicer if this was some sort of GUID and we would get the option to reset this GUID when renaming the class. Here are some examples for legitimate reasons: Code distribution (Daklu's case). Spelling mistakes (Oh, I forgot to type the F in "shift"?). Changes in the class subject (I first encountered this issue when The Device was nearing the end of the development and marketing gave it its final production name. "OK, I'll just rename the class", thought I). I would really like to avoid this. The class name is supposed to be descriptive and having different names will just create confusion (see case 3 above). For further reading, you may wish to have a look at the preserving class data document: http://zone.ni.com/devzone/cda/tut/p/id/6316

For some reason I seem to also have a vague recollection of seeing something like that. Tag Name is a required input, so you have to wire it, but maybe there's a special string for this? An empty string, * and ? don't work. It's quite possible I'm confusing this with something else. Also, one correction (not that it's particularly important) - the methods belong to the Generic class, not GObject.

Not as far as I know. You could try hacking it out of the binary data, but I don't think it's worth the effort. I have some vauge recollection that the tags are saved somewhere in the VI in a global table (i.e. separate from the control itself), but that's an implementation detail and not much help if you don't know what the binary structure of the VI is. In any case, this is less of an issue than it might seem at first, because to do something with the tag you need to have code running which expects the specific tag. I agree that there are cases which potentially could benefit from being able to list tags (e.g. if you want to dynamically invoke some code without having to scan for each of the values in advance), but this can be worked around. Also, just to clarify - the VI class does have a method for getting the tag names. The GObject class does not.

Sort of, but you would have to build it yourself. Both the BD and the FP have a property called Selection List[] which returns an array of reference to all selected objects. You can go over all the objects in that list and get or set their tags. If you want a leg up, there are a few frameworks which allow writing selection-based utilities (JKI right-click framework, Quick Drop shortcuts and LVSpeak, do a search). You can also build a floating tool which will be open all the time which is useful if you're going to do several of those in sequence. Do a search for "scripting springboard" to see an example and a tutorial.

I have to admit I never understood the usefulness of this option. What's the point of a having a VI open if it's not running? If I want to have a VI open automatically, I just set it to open when called.

I didn't look at the code, but I assume it uses the tagging methods. These methods are private and should be available for the GObject class (which tunnels and sequences inherit from). Specifically, there's a Set Tag method which gets a tag name and value. I don't think they're accessible if you use the scripting API, but they should be available if you use the superprivate INI key. LV 8.6 and later has VIs in vi.lib which allow reading and writing tags, but they namespace the tags, so they might not help you.

Note that it also depends on your definition of "reference". Closing a reference will release that reference, but will not necessarily destroy the resource it's pointing to (e.g. if you obtained several references to a queue by name).

Bump.

As do I. That's the method I usually use when I have similar code (not for polling controls, but there are other cases where you can get an array of booleans).

I was refering to the basic construct of building the values into an array and converting to a number. I agree that adding a million empty cases is pointless.

Actually, if the booleans aren't latched or if the user is fast enough, any value between 0 and 511 is possible (although I assume the other cases are actually empty). In any case, it looks like the code comes from an older version of LV (inverted stop condition, B&W VI icon, terminal labels non-transparent) which presumably did not have the event structure, so this code construct would be legitimate.

I suggest you upload your code if you can't solve this. In general, only DVRs do the lock and in fact, that's their defining behavior - they allow you to share a single block of data by locking it when it is accessed. If your code gets stuck, I would guess that you ran into a deadlock - both places are stuck waiting on each other. As mentioned, under normal circumstances this doesn't happen. If the DVR is the only lock you have in the code, make sure the reference wire does not cross the border of the IPE structure into it.

Two relevant points - In 2009, Quick Drop also indexes VIs from the current project, so you can use that to drop VIs from the project. Modern versions (I believe it started in 2009) have the locate in project feature built-in, so there's no longer a need to install the OpenG version. If memory serves, it can be found in the File menu and I believe it has Ctrl+Shift+E assigned as a shortcut.