cross-thread operation

[dani kotlar]

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

 

[Champika Nirosh]

..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.

 

[Marc Gravell]

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

 

[Marc Gravell]

...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

 

[Champika Nirosh]

yes you are correct, I forget it

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

 

[dani kotlar]

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.

 

[Stoitcho Goutsev \(100\)]

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.

 

[Marc Gravell]

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

 

[dani kotlar]

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]

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

 

[dani kotlar]

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]

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

 

[dani kotlar]

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

Thanks a lot

Danny

 

[Marc Gravell]

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

 

[dani kotlar]

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]

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