[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.sdk

Thread Design Problem!!! Help!!!!

Ron

12/24/2002 6:38:00 AM

I'm getting;

'Controls created on one thread cannot be parented to a
control on a different thread.'

exception as a result of one thread inserting nodes into
a XmlDocument and another thread's handler execution;

xmlDocument.NodeInserted += new HodeInsertedHandler
(OnNodeInserted)

It is a listener to the document and tt is called as a
result of the insertion. This handler creates and
attaches new controls to the existing container. That is
when the excption is thrown.

It prevents me from creating seperate threads to executed
actions that take long time to finish. I need to be
asynchronously notified of the action complition in order
to make modifications to my user interface based on the
changes resulting for the thread execution. It sound to
me like a major design problem with .NET.
2 Answers

BrianM

12/25/2002 7:25:00 PM

0

check out BeginInvoke/EndInvoke. I have done some testing and if you call
BeginInvoke and do not maintain a reference to the return object you do not
have to call EndInvoke so it acts exactly like PostMessage/PostThreadMessage
(it would be nice if Microsoft verified this). Invoke acts exactly like
SendMessage (synchronous). Anyway you need to marshall any graphics stuff
back onto the thread that created the graphics context...not much different
than win32/mfc and this is the job of the invoke stuff. For a tutorial,
check out
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/d...
l/winforms06112002.asp

Essentially, whenever you are doing graphics that may be done from a
non-graphics thread, you do an InvokeRequired and if this is true you simply
call Invoke or BeginInvoke to marshall the action onto the correct thread.
If it's not true you just keep going. I have all this contained in the same
method. for example:

class SomeClass
{
public delegate void ProcStringDataDelegate(string msg);
.
.
.
public void ProcessTreeData(string sMsg)
{
if(this.IsDisposed) // I found this handy in case a close gets posted
before you're invoke makes it thru....
return;
if(this.InvokeRequired)
{
// handle the tree updating synchronously. Use BeginInvoke instead
of Invoke to do async...
ProcStringDataDelegate psdd = new
ProcStringDataDelegate(this.ProcessTreeData);
Invoke(psdd, new object[] { sMsg });
}
else
{
// put your custom processing of the message marshalled onto the
correct thread here...
}
}
}


"Ron" <namortaror@hotmail.com> wrote in message
news:035301c2ab0e$bc5fc500$d7f82ecf@TK2MSFTNGXA14...
> I'm getting;
>
> 'Controls created on one thread cannot be parented to a
> control on a different thread.'
>
> exception as a result of one thread inserting nodes into
> a XmlDocument and another thread's handler execution;
>
> xmlDocument.NodeInserted += new HodeInsertedHandler
> (OnNodeInserted)
>
> It is a listener to the document and tt is called as a
> result of the insertion. This handler creates and
> attaches new controls to the existing container. That is
> when the excption is thrown.
>
> It prevents me from creating seperate threads to executed
> actions that take long time to finish. I need to be
> asynchronously notified of the action complition in order
> to make modifications to my user interface based on the
> changes resulting for the thread execution. It sound to
> me like a major design problem with .NET.


Dino Viehland \(MS\)

1/7/2003 10:48:00 PM

0

Brian,

You are correct that Ron needs to call Control.Invoke or
Control.BeginInvoke to have the method executed by the thread that owns the
window handle. But, it is absolutely necessary that you call EndInvoke on
any async calls. If this works today it is really just due to luck (and our
implementation details). In the future the implementation could change. If
that happens not calling EndInvoke could lead to unexpected behavior.

(The lawyers love disclaimers: This information is provided as is, no
warranty, express or implied, etc, etc, etc...)

"BrianM" <mccorb@cox.net> wrote in message
news:#zRmGqDrCHA.2296@TK2MSFTNGP09...
> check out BeginInvoke/EndInvoke. I have done some testing and if you call
> BeginInvoke and do not maintain a reference to the return object you do
not
> have to call EndInvoke so it acts exactly like
PostMessage/PostThreadMessage
> (it would be nice if Microsoft verified this). Invoke acts exactly like
> SendMessage (synchronous). Anyway you need to marshall any graphics stuff
> back onto the thread that created the graphics context...not much
different
> than win32/mfc and this is the job of the invoke stuff. For a tutorial,
> check out
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/d...
> l/winforms06112002.asp
>
> Essentially, whenever you are doing graphics that may be done from a
> non-graphics thread, you do an InvokeRequired and if this is true you
simply
> call Invoke or BeginInvoke to marshall the action onto the correct thread.
> If it's not true you just keep going. I have all this contained in the
same
> method. for example:
>
> class SomeClass
> {
> public delegate void ProcStringDataDelegate(string msg);
> .
> .
> .
> public void ProcessTreeData(string sMsg)
> {
> if(this.IsDisposed) // I found this handy in case a close gets
posted
> before you're invoke makes it thru....
> return;
> if(this.InvokeRequired)
> {
> // handle the tree updating synchronously. Use BeginInvoke instead
> of Invoke to do async...
> ProcStringDataDelegate psdd = new
> ProcStringDataDelegate(this.ProcessTreeData);
> Invoke(psdd, new object[] { sMsg });
> }
> else
> {
> // put your custom processing of the message marshalled onto the
> correct thread here...
> }
> }
> }
>
>
> "Ron" <namortaror@hotmail.com> wrote in message
> news:035301c2ab0e$bc5fc500$d7f82ecf@TK2MSFTNGXA14...
> > I'm getting;
> >
> > 'Controls created on one thread cannot be parented to a
> > control on a different thread.'
> >
> > exception as a result of one thread inserting nodes into
> > a XmlDocument and another thread's handler execution;
> >
> > xmlDocument.NodeInserted += new HodeInsertedHandler
> > (OnNodeInserted)
> >
> > It is a listener to the document and tt is called as a
> > result of the insertion. This handler creates and
> > attaches new controls to the existing container. That is
> > when the excption is thrown.
> >
> > It prevents me from creating seperate threads to executed
> > actions that take long time to finish. I need to be
> > asynchronously notified of the action complition in order
> > to make modifications to my user interface based on the
> > changes resulting for the thread execution. It sound to
> > me like a major design problem with .NET.
>
>