By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,986 Members | 1,193 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,986 IT Pros & Developers. It's quick & easy.

exception

P: n/a
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
Nov 16 '05 #1
Share this Question
Share on Google+
18 Replies


P: n/a
Just a quick thought...

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

ShaneB

"Itzik" <it****@pisgasys.co.il> wrote in message
news:uv**************@TK2MSFTNGP09.phx.gbl...
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

Nov 16 '05 #2

P: n/a
i am using this
[STAThread]

static void Main()

{

Application.Run(new FrmDataEntryWeighing());

}
"ShaneB" <st********@yahoo.com> wrote in message
news:uD**************@TK2MSFTNGP15.phx.gbl...
Just a quick thought...

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

ShaneB

"Itzik" <it****@pisgasys.co.il> wrote in message
news:uv**************@TK2MSFTNGP09.phx.gbl...
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


Nov 16 '05 #3

P: n/a
more information:
this form is not my start form.
"ShaneB" <st********@yahoo.com> wrote in message
news:uD**************@TK2MSFTNGP15.phx.gbl...
Just a quick thought...

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

ShaneB

"Itzik" <it****@pisgasys.co.il> wrote in message
news:uv**************@TK2MSFTNGP09.phx.gbl...
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


Nov 16 '05 #4

P: n/a
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" <it****@pisgasys.co.il> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...
more information:
this form is not my start form.
"ShaneB" <st********@yahoo.com> wrote in message
news:uD**************@TK2MSFTNGP15.phx.gbl...
Just a quick thought...

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

ShaneB

"Itzik" <it****@pisgasys.co.il> wrote in message
news:uv**************@TK2MSFTNGP09.phx.gbl...
> 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

Nov 16 '05 #5

P: n/a
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/<#8**************@TK2MSFTNGP15.phx.gbl>

more information:
this form is not my start form.

Nov 16 '05 #6

P: n/a
Thank you is work
Can you explain me this

"Richard Blewett [DevelopMentor]" <ri******@NOSPAMdevelop.com> wrote in
message news:uI**************@TK2MSFTNGP09.phx.gbl...
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/<#8**************@TK2MSFTNGP15.phx.gbl>
more information:
this form is not my start form.

Nov 16 '05 #7

P: n/a
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#**************@TK2MSFTNGP11.phx.gbl>

Thank you is work
Can you explain me this

"Richard Blewett [DevelopMentor]" <ri******@NOSPAMdevelop.com> wrote in
message news:uI**************@TK2MSFTNGP09.phx.gbl...
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


Nov 16 '05 #8

P: n/a
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

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 16 '05 #9

P: n/a
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/<u7**************@TK2MSFTNGP09.phx.gbl>

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.
Nov 16 '05 #10

P: n/a
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

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 16 '05 #11

P: n/a
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/<e5**************@TK2MSFTNGP12.phx.gbl>

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!
Nov 16 '05 #12

P: n/a
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/<e5**************@TK2MSFTNGP12.phx.gbl>

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!
Nov 16 '05 #13

P: n/a

"Richard Blewett [DevelopMentor]" <ri******@NOSPAMdevelop.com> wrote in
message news:%2****************@TK2MSFTNGP14.phx.gbl...
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.

Nov 16 '05 #14

P: n/a

"Richard Blewett [DevelopMentor]" <ri******@NOSPAMdevelop.com> wrote in
message news:%2****************@TK2MSFTNGP14.phx.gbl...
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.

Nov 16 '05 #15

P: n/a
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/<er**************@TK2MSFTNGP14.phx.gbl>
"Richard Blewett [DevelopMentor]" <ri******@NOSPAMdevelop.com> wrote in
message news:%2****************@TK2MSFTNGP14.phx.gbl...
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]
Nov 16 '05 #16

P: n/a
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/<er**************@TK2MSFTNGP14.phx.gbl>
"Richard Blewett [DevelopMentor]" <ri******@NOSPAMdevelop.com> wrote in
message news:%2****************@TK2MSFTNGP14.phx.gbl...
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]
Nov 16 '05 #17

P: n/a
"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

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 16 '05 #18

P: n/a
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.

Nov 16 '05 #19

This discussion thread is closed

Replies have been disabled for this discussion.