Thread Abort and DataGrid Question

  • Thread starter Thread starter Gidi
  • Start date Start date
G

Gidi

Hi,

In my Windows application, I'm using thread, and I've 2 questions:

1. I read that it's not recommended to use Thread.Abort(), so what is the
best way to close the thread, in case the user wants to cancel or the thread
is finished and i want to close my application?

2. in my Thread I'm creating a dataGridView with DataTable as dataSoruce,
and I've problem with the scroll bars, I see the scroll bars but both of the
are frozen and i can't scroll between the lines, but if i'm using the middle
button in my mouse it does scroll. I took my code to another Win Form without
thread and i don't have this problem there, so my guess is that it's releated
to thread.
Does anyone have any idea?

Thanks,
Gidi.
 
Thread Abort can be bad because there is no way of telling what state the
thread will be interrupted in. I'm guessing that calling Thread.Abort on a
one-way process where _none_ of the data it is modifying is shared (although
this can be difficult to guarantee) could be okay.

However generally speaking it's better to have background threads waiting on
some kind of boolean value which you then toggle when disposing/stopping the
thread. This means the threads reaches the end of it's method and just
returns.

e.g.

while(!isDisposed)
{
// perform background processing
}

// thread exits here

Furthermore your datagrid problem is definately _not_ related to threads per
se. This is because the UI in Winform apps in inherently single threaded.
Accessing a WinForm control on a background thread will cause an exception to
be thrown.

HTH

Simon
 
Thanks Simon,

if my dataGridView problem doesn't releated to the thread, what can casue
this problem? and why it works fine on a regular win form and doesn't work
here?

Thanks,
Gidi
 
On Jul 30, 11:43 am, Simon Tamman

Furthermore your datagrid problem is definately _not_ related to threads per
se. This is because the UI in Winform apps in inherently single threaded.
Accessing a WinForm control on a background thread will cause an exception to
be thrown.
Click to expand...

That only happens under the debugger, by default. In release it will
just silently let you try to update the UI from the wrong thread.

Jon
 
It could be lots of things, which is why I haven't answered that question. I
would suggest that you extract the problem into a very small but complete
sample application and work out precisely exactly what is causing the issue.
I would expect that your threaded code is doing something else that the
other code isn't (it might be in the threads or maybe somewhere else
completely!). Perhaps the grids are Enabled = false? Just a guess.
 
Really? oOo I never knew. Thanks Jon.
As an aside, where has your blog gone? All I see these days is a login
screen to mvp blogs.... or page not found. Has you killed it?
 
Hi,

The problem was that i had to invoke the dataSource Binding,

I solved the problem with:

this.Invoke((MethodInvoker)delegate { summary_dgv.DataSource = summary_dt; });

thanks for the help.
 
Simon Tamman said:
Really? oOo I never knew. Thanks Jon.
As an aside, where has your blog gone? All I see these days is a login
screen to mvp blogs.... or page not found. Has you killed it?
Click to expand...

There was a problem with the upgrade to CS2008, but the blog is still
there. http://www.msmvps.com/jon.skeet will redirect you to
http://msmvps.com/blogs/jon_skeet/Default.aspx which is the "proper"
main page. If you take any entry URLs that have "jon.skeet" in and
change them to "jon_skeet", they should work.
 
Back
Top