.net 2.0 Register DragDrop Failed - STAThreadAttribute

[powella]

Hello,

When I am attempting to start a form (with DragDrop enabled) within a
new thread, I get the following exception. This is ONLY the case with
..NET 2.0 and did not occur in 1.1. I ABSOLUTELY MUST start this form in
a new thread. There is no getting around this. The fact that it
functioned properly when compiled for 1.1 is highly irritating.

{System.InvalidOperationException: DragDrop registration did not
succeed. ---> System.Threading.ThreadStateException: Current thread
must be set to single thread apartment (STA) mode before OLE calls can
be made. Ensure that your Main function has STAThreadAttribute marked
on it.
at System.Windows.Forms.Control.SetAcceptDrops(Boolea n accept)
--- End of inner exception stack trace ---
at System.Windows.Forms.Control.SetAcceptDrops(Boolea n accept)
at System.Windows.Forms.Control.set_AllowDrop(Boolean value)
at Kapsules.frmWidget.InitializeComponent()
at Kapsules.frmWidget..ctor()
at Kapsules.CWidgetThread.Load()
at System.Threading.ThreadHelper.ThreadStart_Context( Object state)
at System.Threading.ExecutionContext.Run(ExecutionCon text
executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()}

I would appreciate any help with this matter, as my posts on the
Microsoft newgroups and websites have gone unanswered. Could be another
one of those lovely 'features' that snuck its way in there.

Thanks

[Mattias Sjögren]

I ABSOLUTELY MUST start this form in a new thread.

Then you must also set the thread's ApartmentState property to STA.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[powella]

Have you not even bothered to read that post? Good lord.

Setting a thread to STA might as well be not starting a new thread at
all. STA threads do not behave any where close to standard MTA threads.
Imagine if you will 30 forms all perfoming some intense operation at
once, continually. Hence the requirement and use of an MTA thread. And
to nip it in the bud before it's even mentioned - No, this cannot be
solved by the BackgroundWorker.

The million dollar questions is how to circumvent Microsoft's
'brilliant' slew of new insanely strict thread safety implementations
to make this function PROPERLY as it did in .NET 1.1.

[Mattias Sjögren]

Have you not even bothered to read that post? Good lord.
More than once. If you have that attitude towards people trying to
help you, I kind of understand why your previous posts have gone
unanswered.

STA threads do not behave any where close to standard MTA threads.
Why exactly is it that your code can't run in an STA? What kind of
work do these threads do that require them all to show UI?

The million dollar questions is how to circumvent Microsoft's
'brilliant' slew of new insanely strict thread safety implementations
to make this function PROPERLY as it did in .NET 1.1.

Certain features - drag and drop being one of them - have always
required running in an STA. It's just that they enforce it now. Even
if you code seemed to work in 1.1 it was still broken.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[powella]

'Even if you code seemed to work in 1.1 it was still broken.'

That's got to be one of the most rediculous things I've ever seen. 'my
car appears to be moving forward when I depress the gas pedal, but in
reality, it's not. mystical forces are afoot!'

I've since Implemented the interfaces myself and have fallen back on
using the OLE DragDrop API set to get this working again. Despite the
MVP's opinion, drag drop most definately works (and safely I might add)
using this method.One might have thought that the people behind .NET
would have fallen back on WM_DROPFILES as an alternative method for
forms started within an MTA thread, but apparently that was just beyond
their capabilities.

At any rate, If anyone should come across this thread and be in the
same situation, please email me and I'll be happy to provide the code
required.

[Lloyd Sheen]

I don't really want to get into an argument but I must verify that code that
"worked" in dot.net prior to V2 would sometimes not work if you try to use
the UI in a thread other than the thread that created the UI.

My app would on occation have a problem that no one could capture. When it
was converted to use V2 , low and behold there was the error indication and
after taking this to task and fixing it we encountered no further problems.

If you want to bash MS then bash them for letting V1/1.1 allow the
compilation of code that they knew would not always work correctly.

Lloyd Sheen

<po*****@gmail.com> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...

'Even if you code seemed to work in 1.1 it was still broken.'

That's got to be one of the most rediculous things I've ever seen. 'my
car appears to be moving forward when I depress the gas pedal, but in
reality, it's not. mystical forces are afoot!'

I've since Implemented the interfaces myself and have fallen back on
using the OLE DragDrop API set to get this working again. Despite the
MVP's opinion, drag drop most definately works (and safely I might add)
using this method.One might have thought that the people behind .NET
would have fallen back on WM_DROPFILES as an alternative method for
forms started within an MTA thread, but apparently that was just beyond
their capabilities.

At any rate, If anyone should come across this thread and be in the
same situation, please email me and I'll be happy to provide the code
required.