ActiveX Control in DLL

[mbrost]

I know that similar problems have been discussed here, but none of the answers seem to fit.

I have a third-party ActiveX control, the control is embedded in a wrapper window (not visible), the ActiveX control is used in a DLL (VC6) which I want to call from Teststand.

When I call the DLL-function it is executed but all the ActiveX stuff doesn't work - no error message or anything. Any idea?
If I call the DLL-function from some test-application
I've written everything works just fine. What am I doing wrong?
I use TS 2.0.1f1/W2K/VC6.
Thanks!

[Scott_Richardson]

To mbrost -

Microsoft requires that ActiveX controls be loaded and called from an STA thread,that is a thread that calls CoInitializeEx(COINIT_APARTMENTTHREADED). When you write an application, typically the GUI thread is STA by default. All of TestStand execution threads are MTA by default ColIntiializeEx(COINIT_MULTITHREADED). TestStand uses MTA threads so that it can easily share ActiveX references without any special preprocessing requirements.

For TestStand 2.x you must wrap all calls to the DLL in code that creates and uses a worker thread to host the the ActiveX control. The worker thread must be initialized as STA and must stay around while the Active control exists. Once the control is destroyed, the thread can be released.

New to Test
Stand 3.0 is an advance sequence call setting that allows an execution thread to call a subsequence in a separate thread but specify that a subsequence call uses an STA thread instead of an MTA thread.

Scott Richardson (NI)

[mbrost]

Thank you for your answer. I'm not sure wether I understood all of it correctly.
I have to create a STA worker thread in my DLL, which uses the ActiveX control. Do I do that in the InitInstance function of my DLL? Is there some example code?
Thank you.

[Scott_Richardson]

Dialogs that display ActiveX controls have the same type of problem in that they must be displayed in an STA thread. TestStand 2.0.1 has an example of this type of dialog:

\Examples\MFCActiveXContainerDlg

You can use this as an example. Keep in mind if the lifetime of the control is within a single step, the thread does not need to stay around. If the lifetime is longer, you must keep the thread around longer.

If you do not intend on TestStand to access the properties and methods of the control directly, another option would be to wrap the control by creating an ActiveX DLL server that hosts the control and TestStand creates an instance of the hosting server which in turn creates an instance of the control. If the
server is defined to be STA, COM should take care of threading issues for you.

Scott Richardson (NI)