Yair

Another option is having a GUI VI which doesn't have any code or has very limited code. The actual logic VI registers for events in the GUI VI dynamically and does the update using VI server. Then you can have several GUI VIs, but I don't think this scheme will work for what you want. From your description, it sounds to me like you want to have the same FP, just with different colors and styles. For that, the method of going through the controls by reference and changing them sounds better to me. I think that you want two clusters - one for the references and one for the colors (or you could do it using a lookup table) and then you can easily do the updating in a subVI. Building the cluster of reference is easy if you use this JKI RCF plugin. The cluster or array of colors can be saved and loaded to an INI file (or several, as Cat suggests) using the OpenG or MGI saving VIs or you could do it as a class, as you suggested. One thing which may help you save some time is Kshif's property saver. I haven't used it myself, so I can't comment, but it's free, so you shouldn't have any problems with trying it out. In any case, if you're using the control updating way, be sure to set the Defer Panel Updates on the panel to T before starting and to F at the end.

We had some obfuscated code in this thread.

To inherit a control you would indeed want an XControl. You should note, however, that XControls are designed to be controls with code behind them, not controls inheriting from the existing LV controls. As such, I believe you won't get the properties of the control you're using in the XControl (I don't remember if you don't get them at all or if you don't get them only if you add your own property, but it doesn't really matter). There should be a tool in the LAVA code repository which allows you to create properties for the control automatically so that it inherits from a specific control. I believe it was created by Ton, but I never used it, so I can't comment on it.

I posted a VI which does this in this thread, but as you said, the attachments are missing. You can use the report to a moderator button on the post to ask the moderator to find the function. I also posted a document in that thread (reply 21) which shows the various plugin overrides you can use. I can't look at either of them at the moment, but if memory serves, the conpane for the VI is the 4-2-2-4 pane with an I32 output wired to the top-right corner. I believe it should be 1 if you want to cancel the creation of a new VI or 0 if you want to allow it (or the other way around, or it might have been 1 and 2).

Science: You propose a hypothesis. You check it against the facts. If the facts contradict the hypothesis it means one of three things: either you got the facts wrong or you got the hypothesis wrong or you misinterpeted the way the two interact. You're welcome to choose which is the correct explanation.

Comedians and wrestlers also work out great (and I'm not even mentioning Reagan, Schwarzenegger or Clint Eastwood). Here's an interesting tidbit I forgot to mention - originally, the job was offered to Albert Einstein (and you really can't get much more scientific than that), but he turned it down.

Here are a few more: Benjamin Franklin Chaim Weizmann - Israel's first president and a proper chemist Ephraim Katzir - Israel's fourth president - a biophysicist Yuval Neeman (no relation to me) - physicist (one of the discoverers of Hadrons) and science minister. Daniel Hershkovitz - A mathematician (he was the dean of the math department in the Israeli eqivalent of MIT) and the current science minister.

I guess that means it's subtle enough.

That was the point. It was put there for the rare occasions when people notice these things. Chris, he said it, not me.

The subtle one. To be fair, the term "pun" isn't really accurate in this case, but I think it should be fairly obvious from the context of my previous post if you look in the right place.

Now that LAVA's added a level at 500 my pun loses some of its meaning. Maybe it's time to find another.

How about adding this to the idea exchange?

Apparently one of my co-workers did a small NI USB DAQ experiment with xVM a while back which didn't succeed. He said it was possible that there were other reasons for it not working, though, so it's possible that it would work today with no problems.

You should note that the for loop has an optional stop terminal (made available with a right click) which is basically similar to the Break command (although unlike Break it will always finish the code in the current iteration). You can use this to stop a for loop prematurely in the cases where the Count property doesn't behave.

Cross post. Sharon, you should not cross post the same message to different places unless you don't get an answer. Even if you do, you should include a link to the other discussion, so that people can look and see that it was answered there.

I'm not a VB developer, but my experience both with the Office API and with various .NET APIs has been that they do have a Count property. Are you saying this isn't a built-in part of collections? I would expect there to be some standard method of retrieving its size.

Can't remember off hand. We may or may not have used it with NI USB DAQ hardware. I could try asking tomorrow. xVM itself has a pretty decent way of interacting with the PC's hardware, if memory serves, so hopefully it should work.

You're assuming the random code would not be the equivalent of a creature with a super-critical mass of fissile material somewhere in its body (e.g. a Delete primitive with "C:\Program Files" wired into the path and a T wired into the recursive input).

I don't think NI has the old versions online, but you might be able to get a copy from your local NI office.

I'm guessing this isn't an option, but if you can get them to approve having a virtual machine, it will probably simplify your life considerably, because then you can install one version on each VM and not have to deal with all the cross installation issues. Pros: Simplifies things (only one version on each machine, and that includes things like MAX and drivers. This is great when you need to support an existing project). You can back up the VM after you installed what you want, so if you ever screw it up, you can immediately get it back to a safe state. Similar to the last, you can start with a base machine configured with all the stuff you need (SCC, etc.), then make copies of it and install the specific stuff. Sun's xVM is free and works great. Cons: IT probably won't approve it. License issues (OS, LV). Takes up hard drive space. Might have issues with hardware (USB, PCI, etc.).

The Sixth Dimension! Because sometimes, five just aren't enough.

Why would it? This is a patch, made to fix relatively urgent bugs. If NI's schedule of recent years is indicative (and it should be, according to NI) you can probably expect the minor release around January or February. I know what you're saying. Futurama didn't really pass that test very well. Personally, I don't like either of the other series (I always thought Futurama was more intelligent more funny), so I can't comment on them.

For something like that, the easiest thing to do is to use a small action engine - the first call primitive resets the flag (a USR) to F, then it monitors the input. If the input or the SR is T, it changes the output SR to T. You then place the VI on the wire leading to the stop condition. If any of the callers inputs T into the VI, it changes the flag to T and causes all the callers to have T as the output. Clear? This doesn't handle places where you need a notification (such as loops driven by event structures or dequeue primitives), but those also have solutions.

Actually, at one point I had the idea of adding a block diagram to a WORM global VI. The diagram would execute once when the VI was changed to run mode, so you could put whatever code you wanted in there. In any other VI, the globals would be read-only. I don't remember if I ever made the suggestion publicly, but I do remember that at the time I saw a serious drawback to that idea, although I don't remember what it was at the moment. I like the idea, but I still see a few drawbacks to it (like what happens if the diagram doesn't finish running, what happens if you need some other code to run to get specific info like config file paths, etc.).

You're right. I haven't considered that the data needs to be shared between all instances. What you want aren't constants. You want variables which are written to the first time you use them. This is something I also want, but the problem is that I never figured out a good mechanism for this. Presumably, you want to get these values from a file, but you might also wish to get them from other places (DB, OS, etc.). If you can guarantee a single write, you can actually sort of do this today fairly easily - all you need to do is open a reference to the global VI at the init phase, get a reference to all the controls and then load values into them (e.g. using the config file VIs). You can flatten and unflatten all the values into strings, or use something like the OpenG VIs or the code you wrote to produce a human-readable file. The only problem with this is that there's no way to guarantee a single write and no way to guarantee that the write will occur before all reads.