Re: Thread-safety in VB+MFC Nested ActiveX controls

Thank you Alexander, But as I mentioend, that control IS hosted in STA using
CAxDialogImpl.

Thread-Safety question:

(*) Though I am using multiple threads initialized using
COINIT_APARTMENTTHREADED, and ActiveX control is also Apartment Threaded, why
should we need to write any thread-safe code? I mean that events and methods
calls will all be directed through message queue - and hence serialized.
Still ACCESS_VIOLATION occurs when event is coming back from the control
into the STA thread.

"Alexander Nickolov" wrote:

> It makes no sense whatsoever to host an ActiveX Control
> in an MTA container. The container must use STA and must
> host each ActiveX Control on the same STA where its
> parent window resides. You can have multiple STAs for
> different forms/container windows, but each ActiveX
> Control must be used only from the STA corrresponding
> to its parent window. MTA and windowing do not mix well
> at all...
>
> --
> =====================================
> Alexander Nickolov
> Microsoft MVP [VC], MCSD
> email: agnickolov@xxxxxxxx
> MVP VC FAQ: http://www.mvps.org/vcfaq
> =====================================
>
> ".Suchit" <Suchit@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:C8C2224D-1322-453C-841B-E4A021805433@xxxxxxxxxxxxxxxx
> > Thank you Alexander for your response. Mine is MTA client (FREE_THREADED).
> > Do you recommend to use STA if possible instead of MTA? The exceptions I
> > see
> > are as follows: Noe that _vbaRaiseEvent is causing an exception (ActiveX
> > is
> > written in VB) Any help?
> >
> > __vbaRaiseEvent+I64X11009C2A 013AF140
> > DllCanUnloadNow+I64X779D7D5D 013AF15C
> > DispCallFunc+I64X6A9FA2FB 013AFAB8
> > BASIC_CLASS_Invoke+I64X6AAA6772 013AFAF8
> > BASIC_DISPINTERFACE_GetTypeInfo+I64X6AAA68E1 013AFB28
> > EVENT_SINK_Invoke+I64X6C3FBF05 013AFBCC Ordinal4036+I64X6C3856CB 013AFC1C
> > Ordinal2797+I64X6C38571D 013AFCC0 Ordinal2795+I64X6C3B99D5 013AFCE0
> > Ordinal6374+I64X6C384680 013AFD08 Ordinal6370+I64X6C3B88EE 013AFD68
> > Ordinal1109+I64X6C3B8AFB 013AFD88 Ordinal1578+I64X09B02E54 013AFDB4
> > DllUnregisterServer+I64X77E3A420 013AFDD4
> > SetWindowPlacement+I64X77E14605 013AFE60
> > TranslateMessageEx+I64X77E15B77 013AFFB4
> > DispatchMessageA+I64X7C57B388 01
> >
> >
> > "Alexander Nickolov" wrote:
> >
> >> I hope by multithreaded client you mean a client that creates
> >> mulktiple STAs. E.g. not a client using MTA.
> >>
> >> I'd start doing real debugging. Nothing in your post suggests
> >> where there might be a problem, though the client is the
> >> place I'd start with first.
> >>
> >> --
> >> =====================================
> >> Alexander Nickolov
> >> Microsoft MVP [VC], MCSD
> >> email: agnickolov@xxxxxxxx
> >> MVP VC FAQ: http://www.mvps.org/vcfaq
> >> =====================================
> >>
> >> ".Suchit" <Suchit@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> >> news:7C3031DB-6A87-4EFE-B66E-F338DAFA2C41@xxxxxxxxxxxxxxxx
> >> > Hi All,
> >> >
> >> > Not sure about thread-safety issues & can following scenario work well:
> >> >
> >> > Let's give some names:
> >> > (1) VB1 = Visual Basic 6.0 ActiveX control, non-windowless, threading
> >> > model
> >> > Apartment
> >> > (2) Cls[..] = array of VB 6.0 Class module maintained inside above
> >> > ActiveX
> >> > control (VB1)
> >> > (3) MFC1 = MFC 6.0 ActiveX control, non-windowless, threading model
> >> > Apartment
> >> >
> >> > Now from a multi-threaded client application, using GIT we are sending
> >> > calls
> >> > to VB1. VB1 internally maintains one instance in Cls[..] array per
> >> > thread.
> >> > This array element again creates one instance of MFC1 control and
> >> > subscribes
> >> > to its events.
> >> >
> >> > Now when MFC1 generates an event, the member of Cls[..] array calls a
> >> > method
> >> > of VB1 parent control. Cls[..] members and VB1 are runtime-late-bound
> >> > using
> >> > Object in VB. Static binding does not work. (this is anotehr strange
> >> > problem)
> >> >
> >> > Now when methods of VB1 are called by Cls[..] member elements, this VB1
> >> > generates events which are sink-ed by multi-threaded client.
> >> >
> >> > This application works well for 10-15 minutes and suddenly generates an
> >> > error:
> >> > Method '~' of object '~' failed.
> >> >
> >> > Is this scenario Thread-Safe? What could be a potential source of
> >> > problems?
> >> > Should I try maintaining a queue in VB1 for receiving event sinks
> >> > (instead
> >> > of
> >> > calling methids directly from Cls[...] objects)? Unfortunately in this
> >> > forum
> >> > I don't know how to attach a diagram. I have a good diagram that
> >> > explains
> >> > the
> >> > visually nesting of our components.
> >> >
> >> > Any help would be great.
> >>
> >>
> >>
>
>
>
.

Relevant Pages

  • Re: SetTimer and Server COM Control questions
    ... the STA thread, either by sleeping/waiting, or with lengthy ... >> telling your client that there's data to retrieve. ... >> Microsoft MVP, MCSD ... >>> This control needs to provide events to the clients. ...
    (microsoft.public.vc.atl)
  • Re: SetTimer and Server COM Control questions
    ... Microsoft MVP, MCSD ... > Even making the control an ActiveX control, ... > server to know that the client won't accept the event, ... >> the STA thread, either by sleeping/waiting, or with lengthy ...
    (microsoft.public.vc.atl)
  • Re: SetTimer and Server COM Control questions
    ... pumping messages in an STA all the time. ... telling your client that there's data to retrieve. ... > This control needs to provide events to the clients. ...
    (microsoft.public.vc.atl)
  • Re: Running GUI application in separate application domain
    ... >I don't think remoting is the issue here and I believe the remoting ... > the assembly in the new appdomain I now set the apartment state to STA. ... host COM based controls or a .NET control that wraps a COM AX ... The performance counters indicate that there are a ton ...
    (microsoft.public.dotnet.framework.clr)
  • Re: Service hangs when accessing ActiveX control
    ... correctly in an STA on the main thread but you are later calling into this ... your OnStart method and then create the form and control in the ThreadStart ... Application.Runto start the message pump. ... > Not specifying any attribute or specifying it as STA results in the same ...
    (microsoft.public.dotnet.framework.interop)