VC++ 2005 problem creating an ActiveX in a secondary Thread

  • Thread starter Thread starter Daniele Piccinini
  • Start date Start date
D

Daniele Piccinini

Hi all,

In my vc++ 2005 dialog based application i need to use a comunication
activex component in a secondary thread:


CFINSAxEFS* pNewAx = new CFINSAxEFS();
if ( !pNewAx->Create( NULL, NULL, CRect( 0,0,0,0), pParent,
pNode->m_nFinsID) )

throw FALSE;

If i use this code in the main dialog it works fine.

If i use this code in a secondary thread, the program execution don't exit
from the pNewAx->Create function and any exception / error will be rised.

The same code compiled in VC++ 6.0 or VC++ 2003 works fine.

Someone can help me?

Thank you.

- Dany -
 
Hi,

Update of my problem..

On start of the app i need to read some settings in xml file doing so:

::CoInitialize( NULL)
Read setting using msxml
::CoUninitialize();

from this point on, the creation of the activex fails.
If i create the activex before the ::CoInitialize( NULL) call it works fine,
but i need to make it after having read the settings.

The problem is the same in vc++6.0 and vc++ 2003.

Thanks.

- Dany -
 
General rule you should adhere to.... only perform GUI related work in the same thread (which is typically the main thread). Worker
threads should never perform GUI functions. This is simply the way Windows was designed.

Brian
 
Hi Daniele,

Thank you for the further information.

I would suspect the problem occurs because you are passing the main thread
window "pParent" as the parent of this control in second thread. This may
cause some problem. As Brian pointed out, all the windows/controls in the
same top-level window should reside in the same thread.

Then, can you tell me why do you want to place this CFINSAxEFS in the
second thread? Thanks in advanced!

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi Daniele,

Further discussion with other MFC experts confirms my suspicion.

Yes. It is a mistake to pass a pointer of a CWnd-derived class across a
thread boundary. Any calls across that boundary that attempt to use the
thread-local storage that MFC maintains for window objects will fail. This
is not specific to ActiveX - it is true for all window class objects in MFC.

So, why do you want to place CFINSAxEFS in the second thread?

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi Jeffrey,

Thank you, and sorry if i'm late with the answer but I've had some problem.

The ActiveX is a Omron comunication tool useful ti perform serial,
ethernet... comunication with Omron Plc device.
I've placed the ActiveX control in a secondary thread so the comunication
delay don't affect the user interface.

I've tried to pass to the ActiveX a pointer to a Cwnd created in the
CWinThread but the creation of ActiveX still fails.

The strange thing is that if i create the activex in the secondary thread
before calling ::CoInitialize( NULL) in the main thread, all works fine.
If i create the activex in the main thread after calling ::CoInitialize(
NULL) function all works fine.

I start to think that this is a specific behaviour of this activex.

Thanks in advanced!

- Daniele -
 
Hi Daniele,

Thanks for your feedback.

The thread that creates the ActiveX control must be the same thread of its
parent window. That is all the GUI stuff must reside in the same thread. If
you did not obey this rule, this is an unsupported scenario and may result
in different strange behavior or failure.

If it is the Omron comunication tool that performs synchronous I/O
operation that blocks your GUI thread, I think this should be a bad design
of Omron.

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Thanks very much Jeffrey for your patience.

I think my scenario is compatible with your description. I try to describe
better.

The main thread, ( those that manage the GUI ) create a secondary
CWinThread.
The seconary CWinThread create the ActiveX and pass it's window as parent
window.
Note that i don't have to show the ActiveX's user interface anywhere, i only
need to call some
of it's function to read/write data from/to the devices in Sync or Asinch
mode.

Thanks.

- Daniele -
 
Daniele Piccinini said:
Thanks very much Jeffrey for your patience.

I think my scenario is compatible with your description. I try to describe
better.

The main thread, ( those that manage the GUI ) create a secondary
CWinThread.
The seconary CWinThread create the ActiveX and pass it's window as parent
window.
Note that i don't have to show the ActiveX's user interface anywhere, i
only need to call some
of it's function to read/write data from/to the devices in Sync or Asinch
mode.
Click to expand...

The problem is that this should be a COM component, not an ActiveX control.
With no need for a GUI, there's no need for any of the ActiveX hosting
machinery. But VB (classic VB, versions 4-6) had poor design-time support
for components, and MS set a bad example by making the MSCOMM.OCX a control
instead of a component, so apparently your vendor committed the same sin.

Take the control off your Form at design-time, and instead add it to a class
object using a WithEvents variable. Possibly if the GUI truly is optional
it can be used this way.
 
Back
Top