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.

I think what is wanted is that there is not a coercion dot, because the coercion never happens. The type should be propagated across the subVI without changing.

This is sort of a non-answer, but it helps me and I think has merit. What I always do in this situation is not pass the refnum back out from the subVI. There is only a refnum input. This prevents the caller from accidentally doing the cast to a more generic class. It has the downside that the calling code is a little uglier, since it can't railroad the refnum wire through for multiple calls to such subVIs.

Beware using Defer FP Updates continuously in a loop, such as for each update to the tree. It will disrupt right click menus and file menus. It will completely dismiss the menu. It will do this even in other VI FPs than the one being deferred, I believe. We have successfully delayed populating trees in terms of child items of parents that aren't expanded, but not items that are off the current scroll region. I would not recommend trying it much. On the other hand, I also wouldn't use a tree control to display anything that needs to be updated continuously. A listbox would be much more efficient because you can just use the Item Names[] property node to update a whole column of text. You can also simulate a hierarchy in a listbox by having a ring above it to select the current visible section, or perhaps a tree to the left where you can select the visible section(s).

I bet it's the order that they arrive at the IPE structure. I really really doubt that VI priority plays any role. For instance, I know for a fact that VI priority does not seem to play a role for queues when two Dequeue operations are competing for the same queue reference. Granted, DVRs may be a little different, but I doubt they're that different.

This is true. However, you don't have to use a generic Object. You can store any ancestor of an object in its private class data. So if there is some parent class that closely resembles the child class, it might be more useful to use that instead of an Object. But either will work fine.

You can use the Bundle function to collect your events and give them custom names. There are two equivalent options here: Bundle the events going into the Register Events function so that you have a cluster with three user events. Give each event whatever custom names you want. Wire the whole cluster into the Register Events function. Register each event individually with three Register Event functions. Then wire the three registration refnums into a cluster. Give each registration refnum in the cluster a unique name. Wire the whole cluster directly into the Dynamic Events terminal of the Event Structure. In summary, you can bundle together both events and event registration refnums and everything pretty much just works. Pretty cool! Play around and let us know.

Yes, there was an improvement in LV2009 for Variant Attributes. You should see a notable performance improvement, and much better scaling adding or finding items in large sets.

I agree it's terrible usability. But I think the reasoning behind it may be functionality-related. Usually nodes that have an error passed in are a no-op. What happens if the left DVR node has an error passed into it? Does it dereference the value? Does it output a default value and leave the reference alone? Even more questionable is what happens if the right DVR node has an error passed into it. What happens then? Do we leave the DVR open, because the close operation doesn't happen? Is the value ignored? Ideally I would like these nodes to have error inputs, but they have no change in behavior when an error is passed in. From a usability and inplaceness perspective that is best. That, however, is completely different than any other function.