Yair

Ah, so working with Shaun's original example, the poly VI would have DB:Init with String.vi and DB:Init with UDL File.vi (one of which would be selected at edit time, based on the inputs or manually) and each child class could override these. Now I get it.

I can't check at the moment, but do DD VIs not require that you have the same conpane for all the VIs (aside from the DD terminal, obviously)? The whole point of poly VIs is that you can have different conpanes ("different" meaning same pattern with different I/O) and that what you wire determines (at edit time) which VI to use based on the difference between the conpanes. It seems to me that this would prevent DD VIs from being polymorphic (unless you used the exact same conpane, which limits this use case considerably). Or am I missing something?

If it's reentrant? If it has unwired shift registers? If it has feedback nodes? If it has local variables?

I have. I actually realized it when I saw the opening shot, but I still had to look at the description to remember exactly what the movie was about, since it's probably been at least a couple of years since I've seen it. If memory serves, I liked it.

Except for those who are killed by rocks? Rocks can be pretty dangerous. I guess it also matters which kind of clock kills you. I mean, it could be a grandfather clock falling on you, it could be a small watch you swallow, maybe you're near Big Ben as your disaster-movie-de-jour is being filmed, or it's an atomic clock and you get radiation poisoning.

It's probably something as simple as a version of LabVIEW or a tool which doesn't do all the sanity checks and verifications, but just loads the VI and allows them to look at it regardless of the problems it may have. It's easy to build such a tool when you have the source code. Agreed, but that's only part of the lesson. Additional parts are (for instance): Backing up the repository itself to an off-site backup (using the "svnadmin hotcopy" command, if memory serves). For example, you can get a couple of USB drives and just bring them in to work on alternating days and run an automated script to backup and copy the files to the HD. Adding comments to your commits so that you know exactly when you changed what. It becomes very convenient, two years down the line, when you want to see what things were like before a specific change was made.

If I understand correctly, I don't think you need a VI for the writing, as you can just use the OpenG VI directly. For the read VI, if I'm understanding correctly, you basically just want a wrapper around the OpenG VI which will also use the Variant to Data primitive to output the cluster. Is this correct? It doesn't sound too hard, because as you said some of the harder parts have already been handled.

Don't put this on me. You were the one who said it was a primitive and who am I to argue with the great AQ? I wouldn't want to find my classes not working come the next release.

No, but there are 30,000 pounds of bananas. I'm sorry, I have a very childish sense of humor sometimes.

Which means that add primitive also supports ...(gasp)... operator overloading?

Yes, but if Mary only had a little lamb, surely that means that less lamb is slaughtered.

It's been a while since I worked with the PDA module, but in previous versions, all you had to do was call the build, which would (behind the scenes) convert the LV code to C and compile it into an EXE using eVC. Then, all you had to do was move the EXE over to the PDA and run it. That said, I never worked with DAQ devices on the PDA, so I can't comment on that. I would assume that the PDA module or NI's site have documents explicitly explaining how to build an app, but if you can't find them, you can try talking to your local NI office.

If you want a clock written in LV which creates a round semi-transparent window, you can find an example here. Read the posts before and after it for more details.

I believe the issue Darren is describing was supposed to have been fixed by the f2 patch, so presumably it's not that. When I have an error and I want to pinpoint the source, what I usually do is delete parts of the code until it stops happening or delete all of the code and then delete less and less until it starts happening. Which method you choose depends on all kinds of factors, but the basic concept is the same. I usually prefer at least deleting all the code first, to make sure the issue isn't with the VI itself.

Hmm, manwich.

You may wish to have a look at the new version of the code capture tool, which has this feature (see video here). It should be noted, though, that the decoration is only applied to the image, so if you change the code, you have to recreate it.

Try talking to Schwarzenegger. Sorry.

If you want protection, place a big red warning comment in the diagram saying that this code can be dangerous.

Ah, yes. That makes more sense. I don't know why that specific change was made, but it should be noted that it was actually part of larger overhaul of the config VIs which changed their internal code and moved them into a library, so that you can longer use the internal VIs.

After the NRA thread, I'm almost afraid of my email client taking action against me, but I'll post anyway, just because this also illustrates the issue discussed in both threads, basically, of lying to further your goal. While it's fun to make fun of Al Gore, he did not claim he invented the Internet. He's a politician, and politicians are at least smart enough to know not to say things like that (unless the politicians are actually scientists who invented something). He said he had a part in the creation of the Internet and he was actually backed by some of the people who did, who verified that he helped push and fund the relevant projects.

It's ONLY OK if you leave the BD unlocked. I hate locked diagrams and those who go looking in the code should know to be careful with stuff like this. As for the snippets, I don't have any real intentions of using even the ones in 2009, but if I did like them and I used an earlier version, I would definitely want an easy way of getting the code.

You scared me for a moment, but this isn't actually true.

You could set the timeout to 0 , although I see what you're saying.

I meant something like this: Another way of doing this, which is similar to Ton's suggestion, but doesn't require another loop, is to place the actual code in the timeout event. You then wire the value that goes into the timeout terminal through a shift register. In the continuous event frame, you pass a small number (let's say 10) into the shift register. When those events stop happening, the timeout event execute, and you push -1 (infinite timeout) into the SR.