exception

I

Itzik

need help

i Have this error in my project:
"An unhandled exception of type 'System.Threading.ThreadStateException'
occurred in system.windows.forms.dll
Additional information: Could not instantiate ActiveX control
'648a5600-2c6e-101b-82b6-000000000014' because the current thread is not in
a single-threaded apartment."

on this row :
this.axMSComm1 = new AxMSCommLib.AxMSComm();

, but if i create new project with one form and put this mscomm32.ocx
it is work thery good and i can get data from com1.
what is the problem ?

Thanks
 
S

ShaneB

Just a quick thought...

Are you missing "[STA Thread]" line in your Main() method?
[STAThread]
static void Main()
{
Application.Run(new Form1());
}

ShaneB
 
I

Itzik

i am using this
[STAThread]

static void Main()

{

Application.Run(new FrmDataEntryWeighing());

}


ShaneB said:
Just a quick thought...

Are you missing "[STA Thread]" line in your Main() method?
[STAThread]
static void Main()
{
Application.Run(new Form1());
}

ShaneB



Itzik said:
need help

i Have this error in my project:
"An unhandled exception of type 'System.Threading.ThreadStateException'
occurred in system.windows.forms.dll
Additional information: Could not instantiate ActiveX control
'648a5600-2c6e-101b-82b6-000000000014' because the current thread is not
in
a single-threaded apartment."

on this row :
this.axMSComm1 = new AxMSCommLib.AxMSComm();

, but if i create new project with one form and put this mscomm32.ocx
it is work thery good and i can get data from com1.
what is the problem ?

Thanks
 
I

Itzik

more information:
this form is not my start form.


ShaneB said:
Just a quick thought...

Are you missing "[STA Thread]" line in your Main() method?
[STAThread]
static void Main()
{
Application.Run(new Form1());
}

ShaneB



Itzik said:
need help

i Have this error in my project:
"An unhandled exception of type 'System.Threading.ThreadStateException'
occurred in system.windows.forms.dll
Additional information: Could not instantiate ActiveX control
'648a5600-2c6e-101b-82b6-000000000014' because the current thread is not
in
a single-threaded apartment."

on this row :
this.axMSComm1 = new AxMSCommLib.AxMSComm();

, but if i create new project with one form and put this mscomm32.ocx
it is work thery good and i can get data from com1.
what is the problem ?

Thanks
 
S

ShaneB

Are you creating any threads other than the main thread?

Without seeing some code or having a way to duplicate the error, it will be
hard to track down from here.

ShaneB

Itzik said:
more information:
this form is not my start form.


ShaneB said:
Just a quick thought...

Are you missing "[STA Thread]" line in your Main() method?
[STAThread]
static void Main()
{
Application.Run(new Form1());
}

ShaneB



Itzik said:
need help

i Have this error in my project:
"An unhandled exception of type 'System.Threading.ThreadStateException'
occurred in system.windows.forms.dll
Additional information: Could not instantiate ActiveX control
'648a5600-2c6e-101b-82b6-000000000014' because the current thread is
not
in
a single-threaded apartment."

on this row :
this.axMSComm1 = new AxMSCommLib.AxMSComm();

, but if i create new project with one form and put this mscomm32.ocx
it is work thery good and i can get data from com1.
what is the problem ?

Thanks
 
R

Richard Blewett [DevelopMentor]

I'll bet that the exception is being raised from a thread other than the main one that maybe calls Application.Run(new Form1()) on a form that has an ActiveX control on it (maybe without realising it). At the start of the thread function put a call to:

Thread.CurrentThread.ApartmentState = ApartmentState.STA;

By default, as a .NET created thread performs COM interop it initializes into the MTA

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<#[email protected]>

more information:
this form is not my start form.
 
I

Itzik

Thank you is work
Can you explain me this



Richard Blewett said:
I'll bet that the exception is being raised from a thread other than the
main one that maybe calls Application.Run(new Form1()) on a form that has an
ActiveX control on it (maybe without realising it). At the start of the
thread function put a call to:
 
R

Richard Blewett [DevelopMentor]

Your code is interfacing into the COM world and as such it has to conform to the way COM sees the world (COM knows nothing about .NET). COM is a binary standard and so needed a way to separate components that were written with thread sensitive toolkits (e.g. VB.NET) and thread sensitive technologies (windows UI, e.g. ActiveX controls) from thread agnostic code (code that really didn;t care what thread it was run on. To do this they created the apartment abstraction. There were mainly two types of apartment (well there were three but one isn't important for this discussion): Single Threaded Apartments (STAs) where a single thread processed all calls for objects that lived in it; the MTA where all other threads doing COM lived and objects there had no control over which thread called them.

All threads had to elect which of these types of apartment they wanted to be in when they initialized the COM runtime (it had to be initialized on every thread). Some types of components would just work slower if they were created from an apartment other than the one they wanted to be in, but some would plain just not work (e.g. ActiveX Controls).

.NET threads don't. by default, initialize the COM runtime as they generally don't need to call COM code. However, the one exception is thread that perform windows UI work. These will often ened up calling ActiveX controls as alot of bits of windows UI (especially the richer controls) are implemented this way. If a .NET thread starts doing COM work it will initialize the COM library based on its ApartmentState value. If the defayults are left as they are then the thread will enter the MTA.

Because many applications perform UI work on teh main thread the application (the one that calls Main), there is a special way to make it enter an STA (the STAThread attribute). However for other threads that attribute isn't acknowleged. So to make sure a thread enters an STA you have to set the ApartmentState of the thread manually.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<O#[email protected]>

Thank you is work
Can you explain me this



Richard Blewett said:
I'll bet that the exception is being raised from a thread other than the
main one that maybe calls Application.Run(new Form1()) on a form that has an
ActiveX control on it (maybe without realising it). At the start of the
thread function put a call to:
 
R

Ravichandran J.V.

In COM Interoperability, when the COM and the .Net components both have
the same apartment models, the CLR's Interop Marshaler will be able to
manage the marshalling but when the apartment models differ if your COM
has a STA Apartment State and the .Net Componennt has a MTA model) then
the COM interop Marshaler will be invoked and since COM does not knopw
.Net's data types there will be an exception.

But it works if you use the Windows Application project because the
Windows Application project creates a Main method with the STAThread
attribute, which makes your .Net client a STA model just like your
ActiveX component hence there is an error. In the other case, your .Net
client was in MTA model and hence there was an exception.


with regards,


J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com
 
R

Richard Blewett [DevelopMentor]

Are you really claiming you can't call across an apartment boundary from managed code to unmanaged code?

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<[email protected]>

In COM Interoperability, when the COM and the .Net components both have
the same apartment models, the CLR's Interop Marshaler will be able to
manage the marshalling but when the apartment models differ if your COM
has a STA Apartment State and the .Net Componennt has a MTA model) then
the COM interop Marshaler will be invoked and since COM does not knopw
.Net's data types there will be an exception.

But it works if you use the Windows Application project because the
Windows Application project creates a Main method with the STAThread
attribute, which makes your .Net client a STA model just like your
ActiveX component hence there is an error. In the other case, your .Net
client was in MTA model and hence there was an exception.
 
R

Ravichandran J.V.

Hey, come on, I didn't make the technology!

When the ApartmentState(s) differ between Com and .Net components and
the communication has to happen across processes then marshalling has to
be adopted, right? In the case of different apartment states,
marshalling is taken care of by the underlying platform to some extent -
the extent being that if the apartment states are similar then the CLR's
Interop Marshaler can take care of most of the marshalling unless there
are non-blittable types involved in which case you need to use the
MarshalAs attribute to solve the purpose. In case of differing apartment
state(s), the COM Interop marshaler takes over and hence, there was an
error as the COM marhaller does not know .Net types.

But, since the Windows Application (in V.Net) inserts a Main method with
a [STAThread] attribute the apartment states are equalized and hence, no
error for the OP.

I hope this answer satisfies your incredulity!

with regards,


J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com
 
R

Richard Blewett [DevelopMentor]

OK - I thought I better check this to ensure they didn't break it since 1.0 alpha (I tested it out then as I was teaching Essential COM in those days).

I just wrote an MTA COM object which took a BSTR as a parameter ( non-blittable) and called it from an application with the STAThread attribute on the Main. So both the Interop and the COM marshaller were involved. Works fine.

I've seen a couple of posts over the last few months that seemed to suggest that performing cross-apartment calls from managed code to unmamaged code wasn't supported. I thought I was maybe just misreading what they were saying and so let it pass. But there is, it seems, some currency in the idea that it doesn't work

There is not just one marshalling layer in place. The RCW uses the interop layer to get into the COM type system and then the COM marsaller (in my case the universal marshaller) builds the COM marshalling info for cross apartment invocation. The object is invoked, then COM marshals the call back to the STA (in my example) and the RCW managed the transition back to the CLR type system.

The crucial reason why you want to use the same apartment type when invoking COM objects is to remove the need for the COM marshalling layer which adds a non-trivial overhead with "chatty" interfaces (ones which perform alot of calls having, say, lots of properties on them).

ActiveX controls have other issues as they are UI code. Its not specifically that they are STA based.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<[email protected]>

Hey, come on, I didn't make the technology!

When the ApartmentState(s) differ between Com and .Net components and
the communication has to happen across processes then marshalling has to
be adopted, right? In the case of different apartment states,
marshalling is taken care of by the underlying platform to some extent -
the extent being that if the apartment states are similar then the CLR's
Interop Marshaler can take care of most of the marshalling unless there
are non-blittable types involved in which case you need to use the
MarshalAs attribute to solve the purpose. In case of differing apartment
state(s), the COM Interop marshaler takes over and hence, there was an
error as the COM marhaller does not know .Net types.

But, since the Windows Application (in V.Net) inserts a Main method with
a [STAThread] attribute the apartment states are equalized and hence, no
error for the OP.

I hope this answer satisfies your incredulity!
 
W

Willy Denoyette [MVP]

Richard Blewett said:
OK - I thought I better check this to ensure they didn't break it since
1.0 alpha (I tested it out then as I was teaching Essential COM in those
days).

I just wrote an MTA COM object which took a BSTR as a parameter (
non-blittable) and called it from an application with the STAThread
attribute on the Main. So both the Interop and the COM marshaller were
involved. Works fine.

Richard,

I suppose that with MTA COM object you mean a "free-threaded" apartmentmodel
COM object, else if it's marked "Both" it will be created on the main STA
thread. Sure, I ain't telling you something new, just to be sure ;-)

Willy.
 
R

Richard Blewett [DevelopMentor]

Nope, ThreadingModel=free
Not ThreadingModel=both

My COM object was deinfitely running in the MTA and the .NET Main thread entered an STA. Want me to post the code?

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<[email protected]>


Richard Blewett said:
OK - I thought I better check this to ensure they didn't break it since
1.0 alpha (I tested it out then as I was teaching Essential COM in those
days).

I just wrote an MTA COM object which took a BSTR as a parameter (
non-blittable) and called it from an application with the STAThread
attribute on the Main. So both the Interop and the COM marshaller were
involved. Works fine.

Richard,

I suppose that with MTA COM object you mean a "free-threaded" apartmentmodel
COM object, else if it's marked "Both" it will be created on the main STA
thread. Sure, I ain't telling you something new, just to be sure ;-)

Willy.






---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.782 / Virus Database: 528 - Release Date: 22/10/2004



[microsoft.public.dotnet.languages.csharp]
 
R

Ravichandran J.V.

"Its not specifically that they are STA based."

The OP states that he or she is able to make it work if the .Net client
is a Windows Forms App, which obviously means that the issue was
resolved because of the [STAThread] attribute to the Main method. So, I
could safely conclude that the ActiveX control was built on STA model
and that the error was not due to any UI issue.



with regards,


J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com
 
R

Richard Blewett [DevelopMentor]

You can only safely conclude that the ActiveX control does not function correctly when loaded into the Host STA (a special STA that apartment threaded components get loaded into when created from the MTA). IIRC this was to do with the way the Windows UI interacts on the Host STA - but its been a few years since I did alot of deep COM work so I might be wrong.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

"Its not specifically that they are STA based."

The OP states that he or she is able to make it work if the .Net client
is a Windows Forms App, which obviously means that the issue was
resolved because of the [STAThread] attribute to the Main method. So, I
could safely conclude that the ActiveX control was built on STA model
and that the error was not due to any UI issue.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top