Thread Abort and DataGrid Question

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

"Gidi" wrote:

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.

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

"Simon Tamman" wrote:

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

"Gidi" wrote:

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.

On Jul 30, 11:43*am, Simon Tamman
<SimonTam...@discussions.microsoft.comwrote:

<snip>

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.

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.

"Gidi" wrote:

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

"Simon Tamman" wrote:

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

"Gidi" wrote:

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.

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?

"Jon Skeet [C# MVP]" wrote:

On Jul 30, 11:43 am, Simon Tamman
<SimonTam...@discussions.microsoft.comwrote:

<snip>

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.

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

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.
"Jon Skeet [C# MVP]" wrote:

On Jul 30, 11:43 am, Simon Tamman
<SimonTam...@discussions.microsoft.comwrote:

<snip>

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.

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

Simon Tamman <Si*********@discussions.microsoft.comwrote:

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?

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.

--
Jon Skeet - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com