Is it possible to seperate an ActiveX control from the GUI thread?

[codeman]

I have an activeX control (*ocx) that we use for communicating with external instruments. We are running into some difficulty because if the communication with the instrument is held up it can take up to 30 seconds to timeout and our LabVIEW user interface is frozen in the mean time. The VI that contains the control itself does not have to be visible and all the subVIs that use the ActiveX reference have been set to run in the "instrument" execution system thread, but the GUI still freezes. Its my theory that since the ActiveX control itself is in a container and part of a front panel, all refernces to it must be executed in the GUI thread. I just wanted to confirm that this was the case. Also if anyb
ody would like to suggest any work arounds, feel free. The only idea I've had so far was to move all use of the ActiveX control to external code, which is not a very attractive solution for us.

[Greg_McKaskle2]

....Also if anybody would like to suggest any work arounds,
> feel free. The only idea I've had so far was to move all use of the
> ActiveX control to external code, which is not a very attractive
> solution for us.

ActiveX controls are loaded into the UI thread and all interactions with
them, property nodes, and invoke nodes, have to take place in the UI
thread/main thread of LV. So, setting the VIs to run in the
instrumentation or other execution systems, doesn't do much good since
each call to the property or invoke will just have to switch back.

What other choices do you have? If the control doesn't have a UI
anyway, it would improve matters if the control were simply an
automation server. The automation server can be set to run in a single
thr
eaded apartment, or a MT apartment. Changing it to MT means that you
will have to deal with protecting the code from being called from
different threads, and having those calls interleaving and competing
with one another. When you change it to be MT, it can tie up other
threads in LV and leave the UI thread alone. Another alternative is to
change the ActiveX control to spin up its own thread and have a method
that initiates, and one that reads the results or returns the status.

Greg McKaskle

[codeman]

Hi Greg,

Unfortunately, we do not control the source for the control. I did devise another work around; quite frankly I'm a little surprised it works. See what you think.

I created a VI which is essentially just the ActiveX control. I build that single VI into a labview executable and enable it as a COM server. I then open an ActiveX session to the executable, get a reference to the VI, and use the GetControlValue method to obtain the COM reference. I didn't think refnums could function across different applications, but apparently the the type descriptor of ActiveX refnums enable it to reference IDispatch and it works. I can use the ActiveX refnum in my application just as though it were part of it. But since the ActiveX control is actually part
of this other executable, calls to it execute in the UI thread of the other app.

The only problem is that you can't have multiple instances of the executable, which means I need multiple executables for multiple ActiveX controls (since I don't wan't the operation of one control to affect others either) .

[Greg_McKaskle2]

> Unfortunately, we do not control the source for the control. I did
> devise another work around; quite frankly I'm a little surprised it
> works. See what you think.
>

That is unfortunate. I'm not sure about your workaround, but there is
something to be said for things that work. I would look to replace this
whenever possible.

Greg McKaskle

[rberger]

Hello:

Can Mr. Codeman or anybody else send me an example VI on how this is performed in reply 3.

Thanks
Robert

[rberger]

I figured out my own problem. Attached is the code for anybody that wants to look at it. However, the EXE pops up when I don't want it to after I call the Automation Open.vi. This is annoying. Anybody know how to eliminate that EXE opening for a brief second?

[Philip_Courtois]

---

codeman wrote: ...you can't have multiple instances of the executable...

---

Hi codeman,

Well, there actually is a way to launch one executable in multiple instances. All you have to do to enable this functionality, is to add the following text to the *.ini file for the executable:

allowmultipleinstances = TRUE

After that, you will get a new instance every time you launch the executable and it's already running. I haven't tried this with ActiveX applications, but in theory it should work too.

Have fun!