Yair

It was. The server crashed and there was no proper backup. The missing things you're seeing are the result of a restore which was performed using a semi-manual process. It's true that LAVA lost some things, but that's no reason to lash out. You could have just asked. P.S. The forums have a feedback forum which is where these things should go. There was also an announcement explaining exactly what the situation was when the forums came back online.

This reminds me of my favorite Futurama joke, from the second episode of the series. Fry (a guy who was frozen for 1000 years) flies into space for the first time and is taken on a tour of the moon. Having watched part of the video Chris uploaded from NIWeek I can agree with Scott. I am not a number. I am a free man!

I am one of those people who do use globals occasionally, so I think that classes only make the use cases where they're legitimate even more legitimate. Before I continue, let me say that I am perfectly aware of the issues with globals. If you need to write in multiple places, you have no way of preventing race conditions short of using some kind of locking mechanism like a semaphore, which is still problematic from a dataflow perspective and can cause deadlocks. So no globals in that case. I'm not really worried about the copy issue, since I use globals for small things. The most legitimate use case is a case where you have a single writer and multiple readers. You could use a notifier with previewing for this (and I would if I need to generate N copies), but if you only need one copy, a global is the easiest method. I wouldn't use a global for something like ref-counting (an LV2 glob is better suited for that due to the race conditions issue), but I would be happy to use read-only globals as constants. I even posted an idea to that effect here. The solution to that is to make the queue unnamed and put its reference into the class data cluster. An equivalent in 2009 is the references to data feature, which doesn't even allow you to name the reference, partly to avoid this issue.

Option B has another Pro, in that it's more consistent with standard events, where you create the event explicitly in the caller VI. I don't have any experience with either method, so I can't comment more.

C'mon, do you guys at VIE have nothing better to do than read LAVA and imagine stuff all day? I guess we need to get crelf to give you more stuff to do.

This naturally reminded me of the FAO Schwartz floor piano (made famous by a classic scene in Big), so a quick search brought me to a video where a couple of the employees put on a show. The sound isn't much (so their rendition of Carol of the Bells doesn't sound great), but near the end (at the 5 minute mark) they do Bach's Tocatta and Fugue in D minor, which is definitely worth watching. They certainly are flexible.

Yes, but did they also add code which acts on that token?

Then they're crazy, I tell you. C-R-A-Z-Y!!!

Congrats. I could paraphrase my recent joke from the NI forums Class Baby{void sleep(int seconds)Ewww FillNappie(fillKind fillKind)HappyPapa MakeAFace()} But I think that asking you to remove her hat to see whether the inheritance mechanism works correctly is a better one.

I thought it was probable that NI handled this, but didn't know the details. Nice.

Without changing the code, you will probably have to reimplement some of the stuff the DD does yourself. If the class has an exposed property which links to its parent (and it probably does have it somewhere), then you can iterate over the override VIs from the bottom class to the top one. You will get an error for each VI which doesn't exist. Of course, this doesn't cover the Call Parent Method issue (the override VIs don't have to use it).

I realized today that you can do this with a timed sequence, as one of its outputs is the time the frame took to execute. This alleviates the need for scripting completely at the price of having to load the sequence and the space its nodes take on the BD.

If I understand what you want correctly, you can do this: Wire the class wire into the Get LV Class Path VI. This should return the path of the specific class on the wire. Use that path to open a ref to the VI (it should already know it's a part of the class) or append the DD VI name to the class if it's already in memory (remember that you need to use the format A.lvclass:myVI.vi to get a fully qualified name) and use that to open the reference and run the VI. I don't remember ever running DD VIs using the Run VI method, but I believe this should work.

The VI will have to update to the new version, because it doesn't keep any information about the subVI other than what it needs (name, connector data, etc.). Two pitfalls I can think of: You change the connector of the subVI. The caller VI will probably break. You change the inplaceness of data that goes through the subVI. If the caller holds this data itself and NI didn't write this correctly, you could have a data-erasing bug on your hands. That said, this is just a guess as to something that might happen. It's quite possible that NI did handle this case. In general, I would say that any VI which has its BD removed should not have its subVIs changed under its feet.

It should also be pointed out that not all toolkits and modules are supported in Linux.

Typedefs have definitely been in LabVIEW 6.1. If memory serves, they were introduced around the 5.x timeframe. In LabVIEW, a typedef is a control (usually a .ctl file) which defines a data type. When you change the control, any place in your code which uses the typedef is updated accordingly. This is best for clusters (where you want to add or change elements) and enums (where you want to add or change values), but is also relevant for other things sometimes. If you are using clusters or enums, practically every one of them which is used in more than one place should be a typedef. You should read this for more.

Any topic.

One addition - the AB also keeps the FPs in these cases: VIs which are set to have their FP open (duh) VIs which are explicitly marked in the AB as "don't remove FP". VIs which have property nodes statically linked to controls on their FPs (useful if you want to keep an FP in the EXE without explicitly setting it in the AB). Probably all VIs if you enable debugging (guess), but that's not really relevant in this case.

I can now definitely say the problem still exists after the update.

I prefer "cleverly packaged". Also, Vimeo says it allows uploading 500 MBs a week (although I didn't see a specific mention of single file sizes).

Yes, although not here - http://decibel.ni.com/content/thread/3481?tstart=0. In that thread I posted an initial version I did which does the work but has two disadvantages - It's very messy. It doesn't clean up the code, so it really doesn't look nice. I'm attaching a more recent version of that VI, but it still has these two basic issues (although less). Add Timing Code.zip

Is this on a specific action you're trying to perform or in any action? There are certain operations in LabVIEW which clear the undo buffer.

Paint.NET (Windows only) is a simple yet fairly powerful app. GIMP is the classic example, but has a higher learning curve and a UI which requires getting used to.

You can try doing a search for "free file hosting". The video will be a file, not streaming, but I don't think that should be an issue. Mediafire, for instance, seems to allow 200 MB files without even registering.

Shaun, the problem is not with the VI ref, but with other refs opened inside the dynamic VI. The general rule for reference cleanup is that a reference is automatically destroyed when the top-level VI in the hierarchy where it was created stops running. In this case, the dynamic VI is the top level VI. What you want to do for something like this is change the hierarchy which owns the reference. One way of doing this is to make sure the LV2 global is first loaded in a hierarchy which remains in memory (e.g. by having your main VI call it first). Another is to move the reference generation to a daemon which runs continuously and stays in memory. The daemon can accept requests using mechanisms like queues or user events.