cross-thread operation

..net it self it run on a thread so you are attampting to cross refer to the
application thread.

use form timer to do any UI updates.. System.Windows.Form.Timer will solve
this problem..

in ur case you may set a static variable which update by the RunServer
method where it will pick by the form timer and does the UI update time to
time.

Nirosh.

"dani kotlar" <da*********@gmail.comwrote in message
news:11**********************@c28g2000cwb.googlegr oups.com...

>I am trying to make a client-server application to run, but I am
running into this problem:
in the server Form the call InitializeComponent(); creates a text-box.
Later the calls:
readThread = new Thread(new ThreadStart(RunServer));
readThread.Start();
attemt to update the textbox (in the function RunServer).
I get an exception saying that cross thread operation is invalid as
there is an attempt to access a texbox created in a nother thread.

what should I do?

Danny K

Simple; the spawned thread cannot talk to the TextBox directly; you need to
use .Invoke or .BeginInvoke to switch threads, and ask the UI thread to do
it on your behalf...

If you are just reading the value, another option is to read the value
*before* spawning the thread, and make the value available to the spawned
thread. In 2.0 this is easy with captured variables and anonymous delegates:

string currentText = textbox1.Text;
Thread readThread = new Thread(
(ThreadStart)delegate {
SomeFunctionWithParams(currentText);
});
readThread.Start();

Similarly, for updating:

string newValue = "abc";
textbox1.BeginInvoke((MethodInvoker) delegate {
textbox1.Text = newValue;
});

Note that BeginInvoke will run in parallel, so don't change newValue after
this, as the "textbox1.Text = newValue;" line might not have run yet. You
can use Invoke to run in series, but this can cause issues if the UI thread
is currently waiting for your thread to do something (deadlock). But it
probably shouldn't be anyway.

A final note - for updates you could also have a spooler type approach with
the two threads simply talking to (synchronised) objects / variables - and
the UI updating itself on a timer. This can allow you to combine multiple
logical updates in a single UI update, but requires a timer. Different hats
for different heads.

Marc

...you may set a static variable...

I wouldn't recommend "static" here... the OP didn't mention that the form
was a singleton, so using static could introduce bugs when multiple form
instances are open. As a general rule, keep things as tightly scoped as
possible; these variables relate to an instance of a form, so if using a
timer-based approach (see other post), then use form-level (instance) fields
/ properties.

Marc

yes you are correct, I forget it

"Marc Gravell" <ma**********@gmail.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

>...you may set a static variable...

I wouldn't recommend "static" here... the OP didn't mention that the form
was a singleton, so using static could introduce bugs when multiple form
instances are open. As a general rule, keep things as tightly scoped as
possible; these variables relate to an instance of a form, so if using a
timer-based approach (see other post), then use form-level (instance)
fields / properties.

Marc

I did that and it works. Thank you.
However, pat fo the times I get the same exception as before, and in
other times I get an exception saying:
Invoke or BeginInvoke cannot be called on a control until the window
handle has been created.

What does this mean?
How do I fix it?
Thanks in advance.
Marc Gravell wrote:

Simple; the spawned thread cannot talk to the TextBox directly; you need to
use .Invoke or .BeginInvoke to switch threads, and ask the UI thread to do
it on your behalf...

If you are just reading the value, another option is to read the value
*before* spawning the thread, and make the value available to the spawned
thread. In 2.0 this is easy with captured variables and anonymous delegates:

string currentText = textbox1.Text;
Thread readThread = new Thread(
(ThreadStart)delegate {
SomeFunctionWithParams(currentText);
});
readThread.Start();

Similarly, for updating:

string newValue = "abc";
textbox1.BeginInvoke((MethodInvoker) delegate {
textbox1.Text = newValue;
});

Note that BeginInvoke will run in parallel, so don't change newValue after
this, as the "textbox1.Text = newValue;" line might not have run yet. You
can use Invoke to run in series, but this can cause issues if the UI thread
is currently waiting for your thread to do something (deadlock). But it
probably shouldn't be anyway.

A final note - for updates you could also have a spooler type approach with
the two threads simply talking to (synchronised) objects / variables - and
the UI updating itself on a timer. This can allow you to combine multiple
logical updates in a single UI update, but requires a timer. Different hats
for different heads.

Marc

Dani,

This is by design. Windows controls are connected to the thread that created
them and can be modified only by this thread. In order to modify the control
you execute the modifying code in the thread created the cotntrol. To do
that all controls provide Invoke and BeginInvoke methods. Use those methods
to marshal the excution to the UI thread and modify the control form there.
Google the newsgroups for Control.Invoke there are tons of posts with sample
code; there are also article on MSDN.
--
HTH
Stoitcho Goutsev (100)
"dani kotlar" <da*********@gmail.comwrote in message
news:11**********************@c28g2000cwb.googlegr oups.com...

>I am trying to make a client-server application to run, but I am
running into this problem:
in the server Form the call InitializeComponent(); creates a text-box.
Later the calls:
readThread = new Thread(new ThreadStart(RunServer));
readThread.Start();
attemt to update the textbox (in the function RunServer).
I get an exception saying that cross thread operation is invalid as
there is an attempt to access a texbox created in a nother thread.

what should I do?

Danny K

Invoke and BeginInvoke work (IIRC) using the message pump, and this can only
happen once they have been created in the Win32 sense, and have Win32
handles.

This typically means you haven't shown your form yet, so Show() it;
alternatively, if you are subclassing Form (i.e. you have a MyForm.cs or
similar), then you might be able to get away with calling the protected
method CreateHandle(). Personally, I'd just Show() the form...

Does this help?

Marc

Marc,
I am not sure what you mean by Show(). The form was opened by creating
a new instance of the form:
Application.Run(new Server());
Can you be more specific?
By the way, in visual studio 7 the original program runs fine and there
is no problem with cross-thread operation. Is this a new feature of
Visual studio 8?
Thanks

Danny

Marc Gravell wrote:

Invoke and BeginInvoke work (IIRC) using the message pump, and this can only
happen once they have been created in the Win32 sense, and have Win32
handles.

This typically means you haven't shown your form yet, so Show() it;
alternatively, if you are subclassing Form (i.e. you have a MyForm.cs or
similar), then you might be able to get away with calling the protected
method CreateHandle(). Personally, I'd just Show() the form...

Does this help?

Marc

Application.Run() will indeed Show() the form, so this is fine.

When are you kicking off the worker? Is it perhaps in the constructor? In
which case, depending on timing it is possible that the worker could call
back before Application.Run() has time to Show() the form. If this is the
problem, try kicking off the worker in the Load event instead.

Marc

Marc,
As i am new to .NET programming, excuse me if I am not familiar with
the expression "kicking off the worker "

Danny

Marc Gravell wrote:

Application.Run() will indeed Show() the form, so this is fine.

When are you kicking off the worker? Is it perhaps in the constructor? In
which case, depending on timing it is possible that the worker could call
back before Application.Run() has time to Show() the form. If this is the
problem, try kicking off the worker in the Load event instead.

Marc

sorry, by "kicking off" I mean "starting", and by "worker" I mean "the other
thread in this situation"... i.e. where does the following (from you earlier
post) get called?

readThread = new Thread(new ThreadStart(RunServer));
readThread.Start();

Marc

Marc,
Indeed the call is from the constructor. I guess this is the problem.

Thanks a lot

Danny
Marc Gravell wrote:

sorry, by "kicking off" I mean "starting", and by "worker" I mean "the other
thread in this situation"... i.e. where does the following (from you earlier
post) get called?

readThread = new Thread(new ThreadStart(RunServer));
readThread.Start();

Marc

If you move it into a handler on the Load event, then it will get fired when
the form is shown.

Best of luck,

Marc

Marc,
I moved the lines
readThread = new Thread(new ThreadStart(RunServer));
readThread.Start();

from the form constructor into a button handler, and this solved the
original problem, but then somehow the KeyDown handler of a text box
doesn ot get fired. How come?
Thanks
Dani

Marc Gravell wrote:

If you move it into a handler on the Load event, then it will get fired when
the form is shown.

Best of luck,

Marc

Unless you have good reason to suggest otherwise, I reckon this is
unrelated. The only way it might be connected is if it *is* firing, but
hitting a sync lock.

Any example code (that reproduces without having to hack it)?

Marc