MultiThreading an ActiveX DLL call...

[Cybertof]

Hello,

Is there a good way to call a big time-consumming function from an
ActiveX DLL (interoped) through a thread without blocking the main UI ?

Here are the details :

I have a class CInteropCall encapsulating a call to a visual basic
ActiveX DLL function named FillAlloc_Array Struct_Double() , which is
allocating a big struct array an fills it using a inner loop
(for i = 1 to 300000...)

I'm calling this BigProcess through a thread from the main UI
like this :

CInteropCall MyThreadProcess = new CInteropCall();
Thread m_WorkerThread;
m_WorkerThread = new Thread(new ThreadStart(MyT hreadProcess.Te stMe));
m_WorkerThread. IsBackground = true;
m_WorkerThread. Name = "ThreadLow" ;
m_WorkerThread. Priority = System.Threadin g.ThreadPriorit y.Lowest;
m_WorkerThread. Start();
Here is the TestMe() method from the CInteropCall class which is calling
the function through an instance of a VB6 Class :
public void TestMe()
{
AX_DLL.FillAllo c_ArrayStruct_D ouble(3000000, ref array_struct_do uble);
}
The problem is :
The main UI is blocked when starting the thread, and from time to time
during the thread execution.

Solutions tested :
- adding a Sleep(1) in the inner loop of the vb6 function
It does not change a lot
- adding a DoEvents() in the vb6 function
It does not change a lot but slows down the thread execution.
The same big loop executing from a c# function does not block the main
UI (even without sleep(1)...), the UI remains very smooth.
Any idea to make an interoped vb6 activex call 'UI thread friendly' ?
(or maybe there is no way to do it...)

Regards,
Cybertof.

[Willy Denoyette [MVP]]

"Cybertof" <cy************ @ifrance.com> wrote in message
news:MP******** *************** *@news.wanadoo. fr...

Hello,

Is there a good way to call a big time-consumming function from an
ActiveX DLL (interoped) through a thread without blocking the main UI ?

Here are the details :

I have a class CInteropCall encapsulating a call to a visual basic
ActiveX DLL function named FillAlloc_Array Struct_Double() , which is
allocating a big struct array an fills it using a inner loop
(for i = 1 to 300000...)

I'm calling this BigProcess through a thread from the main UI
like this :

CInteropCall MyThreadProcess = new CInteropCall();
Thread m_WorkerThread;
m_WorkerThread = new Thread(new ThreadStart(MyT hreadProcess.Te stMe));
m_WorkerThread. IsBackground = true;
m_WorkerThread. Name = "ThreadLow" ;
m_WorkerThread. Priority = System.Threadin g.ThreadPriorit y.Lowest;
m_WorkerThread. Start();
Here is the TestMe() method from the CInteropCall class which is calling
the function through an instance of a VB6 Class :
public void TestMe()
{
AX_DLL.FillAllo c_ArrayStruct_D ouble(3000000, ref array_struct_do uble);
}
The problem is :
The main UI is blocked when starting the thread, and from time to time
during the thread execution.

Solutions tested :
- adding a Sleep(1) in the inner loop of the vb6 function
It does not change a lot
- adding a DoEvents() in the vb6 function
It does not change a lot but slows down the thread execution.
The same big loop executing from a c# function does not block the main
UI (even without sleep(1)...), the UI remains very smooth.
Any idea to make an interoped vb6 activex call 'UI thread friendly' ?
(or maybe there is no way to do it...)

Regards,
Cybertof.

You should initialize your (m_WorkerThread ) thread to enter an STA. The way
you do it now results in your COM object to run on the main UI thread.

...
m_WorkerThread. ApartmentState = ApartmentState. STA;
m_WorkerThread. Start();
....

Willy.

[Cybertof]

In article <ej************ *@TK2MSFTNGP10. phx.gbl>,
wi************* @telenet.be says...

You should initialize your (m_WorkerThread ) thread to enter an STA. The way
you do it now results in your COM object to run on the main UI thread. ..
m_WorkerThread. ApartmentState = ApartmentState. STA;
m_WorkerThread. Start();
...

Hi Willy,

That's exactly what I do not want...
I want the thread no to disturb the main UI thread at all.
Cybertof.

[Willy Denoyette [MVP]]

"Cybertof" <cy************ @ifrance.com> wrote in message
news:MP******** *************** *@news.wanadoo. fr...

In article <ej************ *@TK2MSFTNGP10. phx.gbl>,
wi************* @telenet.be says...

I want the thread no to disturb the main UI thread at all.

Sure, but YOU DO disturb the UI by NOT initializing the background thread to
enter an STA, note this is not the UI thread's apartment but a newly created
apartment.
If you don't initialize your backround thread to enter an STA, the AX object
will enter the UI thread's apartment and calls to methods on this object
will run on the UI thread.

Hope it's clear now.

Willy.

[Cybertof]

In article <uK************ **@TK2MSFTNGP09 .phx.gbl>,
wi************* @telenet.be says...

Sure, but YOU DO disturb the UI by NOT initializing the background thread to
enter an STA, note this is not the UI thread's apartment but a newly created
apartment.
If you don't initialize your backround thread to enter an STA, the AX object
will enter the UI thread's apartment and calls to methods on this object
will run on the UI thread.

Hope it's clear now.

Willy.

Thanks, it's more clear.

And should the VB6 ActiveX be compiled with
'Single Threaded' or 'Apartment Threaded' ?
Regards,
Cybertof.

[Willy Denoyette [MVP]]

"Cybertof" <cy************ @ifrance.com> wrote in message
news:MP******** *************** *@news.wanadoo. fr...

In article <uK************ **@TK2MSFTNGP09 .phx.gbl>,
wi************* @telenet.be says...

Sure, but YOU DO disturb the UI by NOT initializing the background thread
to
enter an STA, note this is not the UI thread's apartment but a newly
created
apartment.
If you don't initialize your backround thread to enter an STA, the AX
object
will enter the UI thread's apartment and calls to methods on this object
will run on the UI thread.

Hope it's clear now.

Willy.

Thanks, it's more clear.

And should the VB6 ActiveX be compiled with
'Single Threaded' or 'Apartment Threaded' ?
Regards,
Cybertof.

Apartment.

Willy.

[Cybertof]

In article <#E************ *@tk2msftngp13. phx.gbl>,
wi************* @telenet.be says...

"Cybertof" <cy************ @ifrance.com> wrote in message
news:MP******** *************** *@news.wanadoo. fr...

In article <uK************ **@TK2MSFTNGP09 .phx.gbl>,
wi************* @telenet.be says...

Apartment.

Willy.

STA...Appartmen t...no changes.

I think it's not a problem of thread :

A very very long time is spent during parameter passing.

My array is passe byref, I don't understand why it takes so long time.
Is there any method to pass efficiently an array as a parm to a VB6
ActiveX DLL function ?
Regards,
Cybertof.

[Willy Denoyette [MVP]]

"Cybertof" <cy************ @ifrance.com> wrote in message
news:MP******** *************** *@news.wanadoo. fr...

In article <#E************ *@tk2msftngp13. phx.gbl>,
wi************* @telenet.be says...

"Cybertof" <cy************ @ifrance.com> wrote in message
news:MP******** *************** *@news.wanadoo. fr...

> In article <uK************ **@TK2MSFTNGP09 .phx.gbl>,
> wi************* @telenet.be says...

Apartment.

Willy.

STA...Appartmen t...no changes.

I think it's not a problem of thread :

A very very long time is spent during parameter passing.

My array is passe byref, I don't understand why it takes so long time.
Is there any method to pass efficiently an array as a parm to a VB6
ActiveX DLL function ?
Regards,
Cybertof.

Are you sure that you create the instance of your COM object, and call the
COM method in the same thread procedure?
Failing to do so will incur thread marshaling overhead!

So the STA threading rules are simple;
- initialize your thread to enter an STA.
- call the COM object's methods on the same thread as the one that created
the object instance.

Willy.

[Cybertof]

In article <uk************ **@TK2MSFTNGP14 .phx.gbl>,
wi************* @telenet.be says...

Are you sure that you create the instance of your COM object, and call the
COM method in the same thread procedure?
Failing to do so will incur thread marshaling overhead!

So the STA threading rules are simple;
- initialize your thread to enter an STA.
- call the COM object's methods on the same thread as the one that created
the object instance.

Willy.

Yes, I'm sure, everything is done in the same thread.

As another example, I have removed the 2nd thread creation, and made the
call directly behing a button_click in the main UI Thread.

It's slow when passing the array to the VB6 AX Function, and returning
from the function.

It seems like the array is entirely copied instead of beeing passed
byref. (even if the ref keyword is used during the call...)
Any idea ?

[Willy Denoyette [MVP]]

"Cybertof" <cy************ @ifrance.com> wrote in message
news:MP******** *************** *@news.wanadoo. fr...

In article <uk************ **@TK2MSFTNGP14 .phx.gbl>,
wi************* @telenet.be says...

Are you sure that you create the instance of your COM object, and call
the
COM method in the same thread procedure?
Failing to do so will incur thread marshaling overhead!

So the STA threading rules are simple;
- initialize your thread to enter an STA.
- call the COM object's methods on the same thread as the one that
created
the object instance.

Willy.

Yes, I'm sure, everything is done in the same thread.

As another example, I have removed the 2nd thread creation, and made the
call directly behing a button_click in the main UI Thread.

It's slow when passing the array to the VB6 AX Function, and returning
from the function.

It seems like the array is entirely copied instead of beeing passed
byref. (even if the ref keyword is used during the call...)
Any idea ?

Ok, don't mix two different issues, speed and UI responsiveness. Your
initial issue was that the UI thread was blocked for the duration of the
call, the solution for this was to move this to a background thread, right?
Well, is this issue solved?
If it is, we can have a look at the speed issue, a few questions come to
mind though, how's the speed compared to a VB6 client calling into your
object? Could you post some code?

Willy.