When to use Active X

[DL84]

Hi all,

Thought this might be a good general question.  I go through posts on the message board and it looks a bit like whenever someone is unsure of how to do something complicated, they always ask if active X is needed to program it.

I won't lie I've done it to, mainly in regards to Excel, but thats another beast.

Anyhow, does anyone have a good, to the point answer as to when its a good idea to use Active X, and when its not.  Maybe an answer for what Active X does that can't be done using properties, or manipulating included functions?  Who knows maybe even a short list of ideas that are pretty common in the labVIEW environment that are pretty much agreed upon that Active X is the way to do it, even if its possible with given functions?

Thanks for the contributions, I think this might add some good perspective on the whole topic, for me and countless others!

[Jarrod_S.]

That's quite a broad question! I might not be able to answer it fully, but hopefully I can contribute some...

Let's take a look first at using ActiveX in LabVIEW vs. calling a DLL.

1. The first bonus for using ActiveX is that the ActiveX server (whether it's an ActiveX dll or an application like Excel) exposes properties and methods with (commonly) known datatypes to LabVIEW. It's nice to be able to set properties directly in many cases, rather than using some sort of wrapper function to accomplish that. Furthermore, the methods expose all the input and output arguments and whether they're required or not. This means you don't have to look through some cryptic header file to determine exactly what to input into a given function, and LabVIEW is much less likely to crash if you don't get it just right. Standard DLLs operate pretty much like a black box. LabVIEW passes data into them and has no idea what happens after that. The DLL may end up overwriting parts of LabVIEW's internal memory and wreaking havoc if you don't pass in enough pre-allocated data. If you've heard of .NET, that is taking this one step further by creating a platform with standard datatypes and memory management schemes. For Windows at least, that may be the platform of the future.

2. When you load a DLL in LabVIEW or any other language, you load it into LabVIEW's memory space. This means it's a dependency of LabVIEW. If that DLL is simultaneously being called by another application, there will be two separate copies of it in memory, and they can't communicate with each other at all. ActiveX, on the other hand, allows for communication between separate applications that have distinct memory spaces. This is how you were able to manipulate Excel through LabVIEW. You didn't have to load Excel as a dependency of LabVIEW; you were able to send commands to it across application barriers. So ActiveX can be beneficial if you have two applications that are running independently and need to communicate with each other.

3. One downside of using ActiveX in LabVIEW is that it can sometimes be tedious to navigate through the various levels of the object hierarchy. You doubtless experienced some of this when using Excel. First you open a reference to an application object, then the workbooks object, then a specific workbook, then the worksheets, and so on until you finally get all the way down to the one property you want to read or manipulate. That's a lot of property nodes 😉

4. I'm very much on fuzzy ground with this one, but I have often heard that there's a lot of complexity involved in creating ActiveX-compliant applications and DLLs. Standard DLLs are comparably easy to compile and the process is well understood.

5. Cross-platform compatiblity: ActiveX is definitely Windows-only. You won't be able to port your application to other platforms. This is somewhat true of standard DLLs, too. You can't just port the compiled object code to another platform and expect it to work. But often the source code for the DLLs can be somewhat salvaged and recompiled on the target platform.

OK, that's a start. And take this all with a grain of salt, but it should help get you started!

Message Edited by Jarrod S. on 11-22-2006 03:17 PM

[BillMe]

3. One downside of using ActiveX in LabVIEW is that it can sometimes be tedious to navigate through the various levels of the object hierarchy. You doubtless experienced some of this when using Excel. First you open a reference to an application object, then the workbooks object, then a specific workbook, then the worksheets, and so on until you finally get all the way down to the one property you want to read or manipulate. That's a lot of property nodes

Hah, try programming a TestStand OI to get "property nodes" on the brain.

I've been hoping National Instruments would change that and allow the objects to be "collapsed" if you will into fewer property nodes, similar to using dot notation in Visual Studio.

[PaulG.]

My experience working with ActiveX involved hardware that had no LV drivers, DLL's or CIN components written for it. But they had ActiveX (com). That made it fairly easy to make a decision.

[HJPhilippi]

---

@jarrod S. wrote:
[...]
3. One downside of using ActiveX in LabVIEW is that it can sometimes be tedious to navigate through the various levels of the object hierarchy. You doubtless experienced some of this when using Excel. First you open a reference to an application object, then the workbooks object, then a specific workbook, then the worksheets, and so on until you finally get all the way down to the one property you want to read or manipulate. That's a lot of property nodes 😉

---

Yes, that's very true. And that is why I always ask myself, "When will LabVIEW introduce a dot-notation style object traversal within its .NET/ActiveX nodes?"
That is: A selector that let's me navigate e.g. to the "Application.ActiveWorkbook.Worksheets(n).Cells(a, b)" range object via context menu (at best offering n, a, and b as parameters!), without this never ending chain of subsequent property and method nodes!
😉

Greetings,
Hans

[Lycangeek]

For those using LV 8 or later, try bringing up the class browser. If the property supports a dotted notation (the type of the property is another type in the same TypeLib), you'll see a little blue dot by it. Double click on the property and you'll see them being chained together. When you then drag and drop the property node from the class browser, you'll get a single property node for a.b.c.d, etc.

We're looking for feedback on the class browser as we hope to do more with it. Please feel free to post up your thoughts on it here, in a new thread, or by emailing me at bloggingbrian@gmail.com.

[BillMe]

Brian,
That's a great hint and a great start on condensing the Active-X nodes. I'll try it out and see if I have anything comes to mind for further improvements.