What is wrong with this code. All i am trying to test is 3 progressbar and
one button. On buttonclick i create 3 threads and each thread calls a method
which in turn updates the progressbar and it works. I would to know if this
can be used.
Thanks
private void button1_Click(object sender, System.EventArgs e)
{
ThreadStart job = new ThreadStart(onemethod);
Thread thread = new Thread(job);
thread.Start();
ThreadStart job1 = new ThreadStart(secondmethod);
Thread thread1 = new Thread(job1);
thread1.Start();
ThreadStart job2 = new ThreadStart(thirdmethod);
Thread thread2 = new Thread(job2);
thread2.Start();
}
public void onemethod()
{
for (int i=0;i<100;i++)
{
progressBar1.Value = i;
Thread.Sleep(100);
}
}
public void secondmethod()
{
for (int i=0;i<100;i++)
{
progressBar2.Value = i;
Thread.Sleep(100);
}
}
public void thirdmethod()
{
for (int i=0;i<100;i++)
{
progressBar3.Value = i;
Thread.Sleep(100);
}
} 17 1473
Hi Arun,
The code should work fine, although it violates best practices by
interacting directly with the UI from threads other than the main
thread. Other than that though, it *looks* like it should run just fine.
~d
Arun Kumar wrote: What is wrong with this code. All i am trying to test is 3 progressbar and one button. On buttonclick i create 3 threads and each thread calls a method which in turn updates the progressbar and it works. I would to know if this can be used. Thanks private void button1_Click(object sender, System.EventArgs e)
{
ThreadStart job = new ThreadStart(onemethod);
Thread thread = new Thread(job);
thread.Start();
ThreadStart job1 = new ThreadStart(secondmethod);
Thread thread1 = new Thread(job1);
thread1.Start();
ThreadStart job2 = new ThreadStart(thirdmethod);
Thread thread2 = new Thread(job2);
thread2.Start(); }
public void onemethod()
{
for (int i=0;i<100;i++)
{
progressBar1.Value = i;
Thread.Sleep(100);
}
}
public void secondmethod()
{
for (int i=0;i<100;i++)
{
progressBar2.Value = i;
Thread.Sleep(100);
}
}
public void thirdmethod()
{
for (int i=0;i<100;i++)
{
progressBar3.Value = i;
Thread.Sleep(100);
}
}
DotNet Coder,
I agree, its not the best practices but my point is, if you use threads and
use it carefully it shouldn't be a problem.
Check this link http://www.yoda.arachsys.com/csharp/...winforms.shtml
let me know you comments.
Arun
"DotNet Coder" <d0*********@yahoo.dot.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... Hi Arun,
The code should work fine, although it violates best practices by interacting directly with the UI from threads other than the main thread. Other than that though, it *looks* like it should run just fine.
~d
Arun Kumar wrote: What is wrong with this code. All i am trying to test is 3 progressbar and one button. On buttonclick i create 3 threads and each thread calls a method which in turn updates the progressbar and it works. I would to know if this can be used. Thanks private void button1_Click(object sender, System.EventArgs e)
{
ThreadStart job = new ThreadStart(onemethod);
Thread thread = new Thread(job);
thread.Start();
ThreadStart job1 = new ThreadStart(secondmethod);
Thread thread1 = new Thread(job1);
thread1.Start();
ThreadStart job2 = new ThreadStart(thirdmethod);
Thread thread2 = new Thread(job2);
thread2.Start(); }
public void onemethod()
{
for (int i=0;i<100;i++)
{
progressBar1.Value = i;
Thread.Sleep(100);
}
}
public void secondmethod()
{
for (int i=0;i<100;i++)
{
progressBar2.Value = i;
Thread.Sleep(100);
}
}
public void thirdmethod()
{
for (int i=0;i<100;i++)
{
progressBar3.Value = i;
Thread.Sleep(100);
}
}
Completely wrong... if you use threads and use it carefully, it will
still be a problem. As that article states, "Never invoke any method or
property on a control created on another thread other than Invoke,
BeginInvoke, EndInvoke or CreateGraphics, and InvokeRequired.".
This is not just a golden rule, it is a fact of winforms programming.
When you start messing with objects created in other threads, you start
running into all sorts of problems, like race conditions, deadlocks, etc.
Also, as the author stated, you may get away with it for awhile, but
eventually, your application will start displaying some pretty strange
behaviors and debugging could become a horrible process, especially if
it is threading errors that are killing the app.
HTH,
~d
Arun Kumar wrote: DotNet Coder,
I agree, its not the best practices but my point is, if you use threads and use it carefully it shouldn't be a problem. Check this link http://www.yoda.arachsys.com/csharp/...winforms.shtml
let me know you comments.
Arun
"DotNet Coder" <d0*********@yahoo.dot.com> wrote in message news:%2****************@TK2MSFTNGP12.phx.gbl...
Hi Arun,
The code should work fine, although it violates best practices by interacting directly with the UI from threads other than the main thread. Other than that though, it *looks* like it should run just fine.
~d
Arun Kumar wrote:
What is wrong with this code. All i am trying to test is 3 progressbar and one button. On buttonclick i create 3 threads and each thread calls a method which in turn updates the progressbar and it works. I would to know if this can be used. Thanks private void button1_Click(object sender, System.EventArgs e)
{
ThreadStart job = new ThreadStart(onemethod);
Thread thread = new Thread(job);
thread.Start();
ThreadStart job1 = new ThreadStart(secondmethod);
Thread thread1 = new Thread(job1);
thread1.Start();
ThreadStart job2 = new ThreadStart(thirdmethod);
Thread thread2 = new Thread(job2);
thread2.Start(); }
public void onemethod()
{
for (int i=0;i<100;i++)
{
progressBar1.Value = i;
Thread.Sleep(100);
}
}
public void secondmethod()
{
for (int i=0;i<100;i++)
{
progressBar2.Value = i;
Thread.Sleep(100);
}
}
public void thirdmethod()
{
for (int i=0;i<100;i++)
{
progressBar3.Value = i;
Thread.Sleep(100);
}
}
"Arun Kumar" <ar****@hotmail.com> wrote in message
news:OG**************@TK2MSFTNGP12.phx.gbl... DotNet Coder,
I agree, its not the best practices but my point is, if you use threads and use it carefully it shouldn't be a problem. Check this link http://www.yoda.arachsys.com/csharp/...winforms.shtml
let me know you comments.
Arun
There is nothing "carefully" with this, it may work in this simple sample
and it may work a million times but sooner or later it will break, it's
simply wrong to touch the UI element (a window handle) from a thread other
than the thread that owns the handle.
Willy.
Arun Kumar <ar****@hotmail.com> wrote: I agree, its not the best practices but my point is, if you use threads and use it carefully it shouldn't be a problem.
Not true.
Check this link http://www.yoda.arachsys.com/csharp/...winforms.shtml
Which part of:
<quote>
Never invoke any method or property on a control created on another
thread other than Invoke, BeginInvoke, EndInvoke or CreateGraphics, and
InvokeRequired.
</quote>
gives you the impression that it shouldn't be a problem?
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Alright,
Let me go back a step and tell you what i did in Win32 and I know it may not
be true in "WinForms"(As Microsoft keeps changing things)
I am a Delphi Developer, in Delphi, I got a Mainform with a statusbar and a
Thread which creates database.
I use Synchronize() to update the main form which i believe is correct.
I want to do the same in .Net and after playing around with things and
reading the article. (Correct me if i m wrong here)
1. Creating the Thread from Mainform
2. If the Thread calls a method which updates the mainform, is this wrong?
I dont want to write complex code just update the mainform.
Very simple
Mainform -> Creates Thread -> does some background database stuff, while
doing that it should update the mainform telling the user hey I am still
working on it wait till i complete it and also give them an indication where
its at.
This is what i am looking for and started playing with Threads. If its were
to be Delphi its a "piece of Cake" and I can do it with few lines.
But, I thought .Net is going to make coding lot easier I guess not.
<Article>" class itself, setting it in one thread, retrieving and processing
it in the other (updating the display in the UI thread, for example).
"<Article> Create a Thread to do stuff and create another Thread to update
UI what is going on here???
Anyway there is no point in hitting the wall
Arun
"DotNet Coder" <d0*********@yahoo.dot.com> wrote in message
news:ey**************@TK2MSFTNGP14.phx.gbl... Completely wrong... if you use threads and use it carefully, it will still be a problem. As that article states, "Never invoke any method or property on a control created on another thread other than Invoke, BeginInvoke, EndInvoke or CreateGraphics, and InvokeRequired.".
This is not just a golden rule, it is a fact of winforms programming. When you start messing with objects created in other threads, you start running into all sorts of problems, like race conditions, deadlocks, etc.
Also, as the author stated, you may get away with it for awhile, but eventually, your application will start displaying some pretty strange behaviors and debugging could become a horrible process, especially if it is threading errors that are killing the app.
HTH, ~d
Arun Kumar wrote: DotNet Coder,
I agree, its not the best practices but my point is, if you use threads and use it carefully it shouldn't be a problem. Check this link http://www.yoda.arachsys.com/csharp/...winforms.shtml
let me know you comments.
Arun
"DotNet Coder" <d0*********@yahoo.dot.com> wrote in message news:%2****************@TK2MSFTNGP12.phx.gbl...
Hi Arun,
The code should work fine, although it violates best practices by interacting directly with the UI from threads other than the main thread. Other than that though, it *looks* like it should run just fine.
~d
Arun Kumar wrote:
What is wrong with this code. All i am trying to test is 3 progressbar and one button. On buttonclick i create 3 threads and each thread calls a method which in turn updates the progressbar and it works. I would to know if this can be used. Thanks private void button1_Click(object sender, System.EventArgs e)
{
ThreadStart job = new ThreadStart(onemethod);
Thread thread = new Thread(job);
thread.Start();
ThreadStart job1 = new ThreadStart(secondmethod);
Thread thread1 = new Thread(job1);
thread1.Start();
ThreadStart job2 = new ThreadStart(thirdmethod);
Thread thread2 = new Thread(job2);
thread2.Start(); }
public void onemethod()
{
for (int i=0;i<100;i++)
{
progressBar1.Value = i;
Thread.Sleep(100);
}
}
public void secondmethod()
{
for (int i=0;i<100;i++)
{
progressBar2.Value = i;
Thread.Sleep(100);
}
}
public void thirdmethod()
{
for (int i=0;i<100;i++)
{
progressBar3.Value = i;
Thread.Sleep(100);
}
}
Hey Jon? Didn't you write an article on this very subject? I seem to
remember you mentioning an article sometime last year.
~d
Jon Skeet [C# MVP] wrote: Arun Kumar <ar****@hotmail.com> wrote:
I agree, its not the best practices but my point is, if you use threads and use it carefully it shouldn't be a problem.
Not true.
Check this link http://www.yoda.arachsys.com/csharp/...winforms.shtml
Which part of:
<quote> Never invoke any method or property on a control created on another thread other than Invoke, BeginInvoke, EndInvoke or CreateGraphics, and InvokeRequired. </quote>
gives you the impression that it shouldn't be a problem?
"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... "Arun Kumar" <ar****@hotmail.com> wrote in message news:OG**************@TK2MSFTNGP12.phx.gbl... DotNet Coder,
I agree, its not the best practices but my point is, if you use threads and use it carefully it shouldn't be a problem. Check this link http://www.yoda.arachsys.com/csharp/...winforms.shtml
let me know you comments.
Arun
There is nothing "carefully" with this, it may work in this simple sample and it may work a million times but sooner or later it will break, it's simply wrong to touch the UI element (a window handle) from a thread other than the thread that owns the handle.
Willy.
Thanks for your response.
Yes. I know that. there is nothing called "carefully". I have worked on
Threads alot in Win32 and I know what will have happen." simply wrong to touch the UI element (a window handle) from a thread other than the thread that owns the handle."
True. its a sample, yes I am trying out things what i can and what i cannot
do in .Net and what are the limitations and I strong believe there is
nothing wrong in doing that and putting my words out here and get the best
out it.
Arun
Arun Kumar <ar****@hotmail.com> wrote: Let me go back a step and tell you what i did in Win32 and I know it may not be true in "WinForms"(As Microsoft keeps changing things) I am a Delphi Developer, in Delphi, I got a Mainform with a statusbar and a Thread which creates database. I use Synchronize() to update the main form which i believe is correct.
I'm afraid I don't know what Synchronize() does in Delphi. The "don't
change the UI from a non-UI thread" is a general Win32 rule though.
I want to do the same in .Net and after playing around with things and reading the article. (Correct me if i m wrong here) 1. Creating the Thread from Mainform 2. If the Thread calls a method which updates the mainform, is this wrong?
Yes.
I dont want to write complex code just update the mainform. Very simple Mainform -> Creates Thread -> does some background database stuff, while doing that it should update the mainform telling the user hey I am still working on it wait till i complete it and also give them an indication where its at.
Sure - so use Invoke or BeginInvoke, and you should be fine. There's a
pretty full example in the article.
This is what i am looking for and started playing with Threads. If its were to be Delphi its a "piece of Cake" and I can do it with few lines. But, I thought .Net is going to make coding lot easier I guess not. <Article>" class itself, setting it in one thread, retrieving and processing it in the other (updating the display in the UI thread, for example). "<Article> Create a Thread to do stuff and create another Thread to update UI what is going on here???
You don't create another thread to update the UI - you tell the
existing UI thread to update the UI.
Anyway there is no point in hitting the wall
There's every point in learning how to do it properly though. I suggest
you read the article again, preferably starting at the first page of it
(rather than just the windows forms page) and taking it a bit at a
time. Threading is fundamentally pretty tricky, but it's very useful
too.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
DotNet Coder <d0*********@yahoo.dot.com> wrote: Hey Jon? Didn't you write an article on this very subject? I seem to remember you mentioning an article sometime last year.
I'm not *sure* whether you're being deliberately ironic or not, but the
article the OP mentioned is mine :)
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
I know, its not true. Its sample app and was trying thing out.
Thanks for your response.
Arun
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Arun Kumar <ar****@hotmail.com> wrote: I agree, its not the best practices but my point is, if you use threads and use it carefully it shouldn't be a problem.
Not true.
Check this link http://www.yoda.arachsys.com/csharp/...winforms.shtml
Which part of:
<quote> Never invoke any method or property on a control created on another thread other than Invoke, BeginInvoke, EndInvoke or CreateGraphics, and InvokeRequired. </quote>
gives you the impression that it shouldn't be a problem?
-- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too
Delphi takes care of the complexities of threading in the background for
you, without you having to worry about. Think about both of these
statements:
"One of the really nice features of using Delphi for .NET, is that
delegate functions have been mapped to the address of operator (the @
sign). What is actually happening behind the scenes is that Delphi is
creating a delegate object. Suffice it to say that the code for
languages like C# are more verbose."
"When a worker thread needs to execute a method from the main thread,
the worker thread would block, waiting for the main thread to process
the request. New to TThread, the Queue method provides the ability to
asynchronously call methods in the main thread. By queuing the method
instead of blocking, allows the worker thread to continue without
waiting for the execution of the method placed on the queue. Eventually
the main thread is ready to process the method(s) on the queue, and the
entire queue is processed at once."
from http://bdn.borland.com/borcon2004/ar...,32225,00.html.
Seems to me, that even in Delphi, you do not directly touch controls on
the main thread. Delegates are created for the developer without the
developer actually having to worry about it. In C#, you have to create
your delegates and wire up the sync/async calls yourself.
HTH,
~d
Arun Kumar wrote: Alright, Let me go back a step and tell you what i did in Win32 and I know it may not be true in "WinForms"(As Microsoft keeps changing things) I am a Delphi Developer, in Delphi, I got a Mainform with a statusbar and a Thread which creates database. I use Synchronize() to update the main form which i believe is correct.
I want to do the same in .Net and after playing around with things and reading the article. (Correct me if i m wrong here) 1. Creating the Thread from Mainform 2. If the Thread calls a method which updates the mainform, is this wrong?
I dont want to write complex code just update the mainform. Very simple Mainform -> Creates Thread -> does some background database stuff, while doing that it should update the mainform telling the user hey I am still working on it wait till i complete it and also give them an indication where its at. This is what i am looking for and started playing with Threads. If its were to be Delphi its a "piece of Cake" and I can do it with few lines. But, I thought .Net is going to make coding lot easier I guess not. <Article>" class itself, setting it in one thread, retrieving and processing it in the other (updating the display in the UI thread, for example). "<Article> Create a Thread to do stuff and create another Thread to update UI what is going on here???
Anyway there is no point in hitting the wall
Arun
"DotNet Coder" <d0*********@yahoo.dot.com> wrote in message news:ey**************@TK2MSFTNGP14.phx.gbl...
Completely wrong... if you use threads and use it carefully, it will still be a problem. As that article states, "Never invoke any method or property on a control created on another thread other than Invoke, BeginInvoke, EndInvoke or CreateGraphics, and InvokeRequired.".
This is not just a golden rule, it is a fact of winforms programming. When you start messing with objects created in other threads, you start running into all sorts of problems, like race conditions, deadlocks, etc.
Also, as the author stated, you may get away with it for awhile, but eventually, your application will start displaying some pretty strange behaviors and debugging could become a horrible process, especially if it is threading errors that are killing the app.
HTH, ~d
Arun Kumar wrote:
DotNet Coder,
I agree, its not the best practices but my point is, if you use threads and use it carefully it shouldn't be a problem. Check this link http://www.yoda.arachsys.com/csharp/...winforms.shtml
let me know you comments.
Arun
"DotNet Coder" <d0*********@yahoo.dot.com> wrote in message news:%2****************@TK2MSFTNGP12.phx.gbl. ..
Hi Arun,
The code should work fine, although it violates best practices by interacting directly with the UI from threads other than the main thread. Other than that though, it *looks* like it should run just fine.
~d
Arun Kumar wrote:
>What is wrong with this code. All i am trying to test is 3 progressbar >and one button. On buttonclick i create 3 threads and each thread calls >a method which in turn updates the progressbar and it works. I would to >know if this can be used. >Thanks >private void button1_Click(object sender, System.EventArgs e) > >{ > >ThreadStart job = new ThreadStart(onemethod); > >Thread thread = new Thread(job); > >thread.Start(); > >ThreadStart job1 = new ThreadStart(secondmethod); > >Thread thread1 = new Thread(job1); > >thread1.Start(); > >ThreadStart job2 = new ThreadStart(thirdmethod); > >Thread thread2 = new Thread(job2); > >thread2.Start(); > > > >} > >public void onemethod() > >{ > >for (int i=0;i<100;i++) > >{ > >progressBar1.Value = i; > >Thread.Sleep(100); > >} > >} > >public void secondmethod() > >{ > >for (int i=0;i<100;i++) > >{ > >progressBar2.Value = i; > >Thread.Sleep(100); > >} > >} > >public void thirdmethod() > >{ > >for (int i=0;i<100;i++) > >{ > >progressBar3.Value = i; > >Thread.Sleep(100); > >} > >} >
ROFL... i couldn't remember if it was your's or not and I didn't follw
the link up. I guess the word "Duh" really applies here, hunh? (Next
time, I should really look at the url *before* clicking the link... lol)
~d
Jon Skeet [C# MVP] wrote: DotNet Coder <d0*********@yahoo.dot.com> wrote:
Hey Jon? Didn't you write an article on this very subject? I seem to remember you mentioning an article sometime last year.
I'm not *sure* whether you're being deliberately ironic or not, but the article the OP mentioned is mine :)
Listen bra... just call Invoke(). if you don't like it, go back to wack Delphi!
..NET is ill!!!!
"Arun Kumar" wrote: I know, its not true. Its sample app and was trying thing out.
Thanks for your response.
Arun
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message news:MP************************@msnews.microsoft.c om... Arun Kumar <ar****@hotmail.com> wrote: I agree, its not the best practices but my point is, if you use threads and use it carefully it shouldn't be a problem.
Not true.
Check this link http://www.yoda.arachsys.com/csharp/...winforms.shtml
Which part of:
<quote> Never invoke any method or property on a control created on another thread other than Invoke, BeginInvoke, EndInvoke or CreateGraphics, and InvokeRequired. </quote>
gives you the impression that it shouldn't be a problem?
-- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too
Listen Bro, I can guess you never used Delphi!!! If you don't like to
comment then DON'T comment, Delphi or C# makes no diff... both rocks.
its the .Net platform I am talking about.
Be nice.
..Net rules when you use properly.
"Delphi Hater" <Delphi Ha***@discussions.microsoft.com> wrote in message
news:43**********************************@microsof t.com... Listen bra... just call Invoke(). if you don't like it, go back to wack Delphi!
.NET is ill!!!!
"Arun Kumar" wrote:
I know, its not true. Its sample app and was trying thing out.
Thanks for your response.
Arun
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message news:MP************************@msnews.microsoft.c om... > Arun Kumar <ar****@hotmail.com> wrote: >> I agree, its not the best practices but my point is, if you use >> threads >> and >> use it carefully it shouldn't be a problem. > > Not true. > >> Check this link >> http://www.yoda.arachsys.com/csharp/...winforms.shtml > > Which part of: > > <quote> > Never invoke any method or property on a control created on another > thread other than Invoke, BeginInvoke, EndInvoke or CreateGraphics, and > InvokeRequired. > </quote> > > gives you the impression that it shouldn't be a problem? > > -- > Jon Skeet - <sk***@pobox.com> > http://www.pobox.com/~skeet > If replying to the group, please do not mail me too
Read up on the InvokeRequired property and the Invoke and BeginInvoke
methods.
Basically you should not directly acces the UI thread's objects from a non
UI thread.
--
Bob Powell [MVP]
Visual C#, System.Drawing
Find great Windows Forms articles in Windows Forms Tips and Tricks http://www.bobpowell.net/tipstricks.htm
Answer those GDI+ questions with the GDI+ FAQ http://www.bobpowell.net/faqmain.htm
All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.
"Arun Kumar" <ar****@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... What is wrong with this code. All i am trying to test is 3 progressbar and one button. On buttonclick i create 3 threads and each thread calls a method which in turn updates the progressbar and it works. I would to know if this can be used. Thanks private void button1_Click(object sender, System.EventArgs e)
{
ThreadStart job = new ThreadStart(onemethod);
Thread thread = new Thread(job);
thread.Start();
ThreadStart job1 = new ThreadStart(secondmethod);
Thread thread1 = new Thread(job1);
thread1.Start();
ThreadStart job2 = new ThreadStart(thirdmethod);
Thread thread2 = new Thread(job2);
thread2.Start(); }
public void onemethod()
{
for (int i=0;i<100;i++)
{
progressBar1.Value = i;
Thread.Sleep(100);
}
}
public void secondmethod()
{
for (int i=0;i<100;i++)
{
progressBar2.Value = i;
Thread.Sleep(100);
}
}
public void thirdmethod()
{
for (int i=0;i<100;i++)
{
progressBar3.Value = i;
Thread.Sleep(100);
}
}
"Arun Kumar" <ar****@hotmail.com> wrote in message
news:ey*************@TK2MSFTNGP12.phx.gbl... "Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message news:%2****************@TK2MSFTNGP09.phx.gbl... "Arun Kumar" <ar****@hotmail.com> wrote in message news:OG**************@TK2MSFTNGP12.phx.gbl... DotNet Coder,
I agree, its not the best practices but my point is, if you use threads and use it carefully it shouldn't be a problem. Check this link http://www.yoda.arachsys.com/csharp/...winforms.shtml
let me know you comments.
Arun
There is nothing "carefully" with this, it may work in this simple sample and it may work a million times but sooner or later it will break, it's simply wrong to touch the UI element (a window handle) from a thread other than the thread that owns the handle.
Willy.
Thanks for your response.
Yes. I know that. there is nothing called "carefully". I have worked on Threads alot in Win32 and I know what will have happen." simply wrong to touch the UI element (a window handle) from a thread other than the thread that owns the handle." True. its a sample, yes I am trying out things what i can and what i cannot do in .Net and what are the limitations and I strong believe there is nothing wrong in doing that and putting my words out here and get the best out it.
Arun
These, what you call "limitations", are imposed by "Windows" (Win32), not by
..NET. "Window" handles (just like Win32 Mutexes) have thread affinity, and
as such they shouldn't be used from another thread than the owning thread
(the one that created the window). Every system or framework that runs on
top of this has to repect this very rule, failing to do so will fail sooner
or later.
Note that v2.0 will throw an exception when running your sample in debug
mode, or when the CheckForIllegalCrossThreadCalls property is set to true in
release mode.
Willy. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Anthony_Barker |
last post by:
I have been reading a book about the evolution of the Basic
programming language. The author states that Basic - particularly
Microsoft's version is full of compromises which crept in along the...
|
by: Jane Austine |
last post by:
As far as I know python's threading module models after Java's.
However, I can't find something equivalent to Java's interrupt and
isInterrupted methods, along with InterruptedException....
|
by: David Harrison |
last post by:
I am working on an application on Mac OS X that calls out
to python via PyImport_ImportModule(). I find that if
the imported module creates and starts a python thread,
the thread seems to be...
|
by: Antal Rutz |
last post by:
Hi, All!
I'm new to threading. I have some design questions:
Task: I collect data and store them in an RDBMS (mysql or pgsql)
The question is how to do that with threading?
The...
|
by: CK |
last post by:
I have the following code in a windows service, when I start the windows
service process1 and process2 work fine , but final process (3) doesnt get
called. i stop and restart the windows service...
|
by: Anthony Nystrom |
last post by:
What is the correct way to stop a thread? abort? sleep? Will it start up
again... Just curious... If the thread is enabling a form, if the form is
disposed is the thread as well?
Thanks,
...
|
by: Bob |
last post by:
- For cleanup, is it sufficient to set a Thread to Nothing after it's done?
- It is OK to pass objects out of the thread? (dumb question maybe but I
want to be sure)
- What's the best way to...
|
by: DBC User |
last post by:
I have a background process which reads a table to see if there are any
pending requests. If there are any, then it will start a worker thread
(only 10 allowed at a time) and executes a method. In...
|
by: Steven |
last post by:
I am taking an "advanced" VB.Net course via web at a state university
toward an information science degree. This is my second VB class and
I am kind of disappointed in it. This week we covered...
|
by: frankiespark |
last post by:
Hello all,
I was perusing the internet for information on threading when I came
across this group. Since there seems to be a lot of good ideas and
useful info I thought I'd pose a question.
...
|
by: ryjfgjl |
last post by:
ExcelToDatabase: batch import excel into database automatically...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: jfyes |
last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
|
by: ArrayDB |
last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
|
by: PapaRatzi |
last post by:
Hello,
I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
|
by: af34tf |
last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
| |