Jarrod S

You don't have to choose between classes and polymorphic VIs. You can get the inheritance you want, automatic function selection, and you can make it an edit-time error you choose the wrong read and task creation combination. Check out this example of dummy classes. Open example.vi attached here (saved in LV 2012) to get an idea of what I mean. We have done this in our classes before with great success. In fact this can work better than doing Dynamic Dispatch for your reads, because there is no run-time overhead for LabVIEW to determine what Read VI to call. But you still have the flexibility to define your OOP hierarchy. daq classes.zip

This will cause a copy to be made of the data. The LabVIEW compiler cannot recognize Get Variant Attribute and Set Variant Attribute pairs as being inplace. If you are worried about performance, consider storing a data value reference to the contained object in your variant look-up, so that the only thing copied is a small reference value.

You might see what happens if you do a variant constant wired to a To Variant wired to this invoke node. That would probably work. The invoke node probably wants to treat the incoming data as a variant wrapping the actual data type of the control. An empty variant does not wrap the variant data type, it wraps void.

The standard way to fake this is to have a cluster hard-coded to contain a few entries with a custom scrollbar running down the side. The data you store is an array, but the front panel control is a cluster. Depending on the position of the custom scrollbar, you copy in the selected array subset into the cluster.

This isn't a global solution to the problem, but you can have a VI on the server side that the client can invoke via VI Server to send the IP Address and port of the server's VI Server instance. I do exactly that here with this example I wrote for a remote User Event library.

Is this still a question? Did you figure it out? FYI, Aristos Queue mentioned that renaming a class or moving it into and out of a library will remove its mutation history, since at that point it's considered a different class.

I definitely agree with John's sentiments. Even if you don't specifically require remote access from a client, it's a great mental exercise to help organize the responsibilities of the client and the engine accordingly.

Do note that generally drivers like NI-RIO are not available in the first Beta. Their beta versions usually arrive for the second Beta. So if you sign up now, you'll only be able to test out your host-side app to start with.

There is a VI property to get the window handle. I think it's one of the super secret hidden property nodes. Not sure if scripting support turns it on. On a side note, beware of getting an hWnd by FP title! Danger lurks! We had a huge bug in Vista that all boiled down to this. The problem is that in Vista the little Aero preview windows that pop up when you hover your mouse over a TaskBar item have the same window title as the window they're previewing. This makes it possible to accidentally get an hWnd for the preview window for your VI instead of your VI itself if you call FindWindow when the preview is active. Nasty little bug took us forever to find. Win7 does not seem to have this issue. Stick with the property node.

You can't exactly create a LV driver, but you can use NI-VISA as the driver for a USB device, and then use VISA functions in LV to send USB-RAW communication to the endpoints. This would allow (very) low-level control of the device from LV, even though LV isn't technically the driver. Search VISA and USB-RAW for more info or see here or here to start.

You can't register for events from controls in another application. That functionality doesn't exist. You would need to add code to the exe to facilitate getting this data out. You could do this in a similar way to the example below, which registers for User Events (rather than front panel events) across app boundaries. http://decibel.ni.com/content/docs/DOC-14216 It will take some work, but the solution could be made fairly generic. The basic idea is to have the local app request that the remote app register a particular event on its behalf and forward it the data via some callback.

You can't do this. However, instead of using Value Signaling property nodes you could use User Events. You can even create a User Event that can be registered in the exact same event case as a Value Change event. The trick is to make the User Event data be a cluster with the exact same event data from the original event type. Then, the Source terminal on the event structure could be used to tell if it was a UI event or User Event. Attached is an example (LV2010). More importantly, though, why do you want to know the difference? User Event Overloads.vi

QSM? That's not a LabVIEW feature. Also, there are many many different ways to do QSMs with many different advantages and disadvantages. If poorly developed, then yes, they are a pain. But nothing protects against bad code. Probe Window: Big yes. Terribly painful. Off the top of my head here are the biggest pain points: It's a floating window, so it's forced to stay on top of other windows. Why?!? Don't force this behavior on me! Why is it shocking that I'd want to view other windows on top of the probe window? Since it's floating and I can't put it behind other windows, I regularly minimize it. However, probing a new value does NOT restore it! Wrong wrong wrong. Generic probes don't resize to fit the large amount of space they now have. This means that numeric and string probes only show a small fraction of the content, with no means of seeing it all (other than creating a new probe type). The dialog remembers its last size, but gets confused if it was last maximized. It tries to set its new size to be the size of your monitor, but it is not in a maximized state. Wrong wrong wrong. This forces you to manually restore it to a normal size. I HATE this. Especially when it's so common that you want to maximize the probe window to get the most out of it. Shared Variables: Definitely agree. Now that you can dynamically read and write to them, why can't you programmatically create Shared Variables on the fly without the DSC module?

Make sure to use a non-blank string for the IP Address. A blank string indicates the local application instance, regardless of the port specified. I've made that mistake, too. Instead use the string "localhost".

I have seen this error happen before for classes that belonged to a LV library. They would fail to be unflattened with this error even though the class was indeed in memory. I believe this bug was fixed in LV2009.