Zytan said:
Sorry for that. Google groups was not working, and I didn't think my
posts were being made. Then I seen new posts appearing, without mine,
so I posted again.
As a point of information:
As is the case with all newsgroups, this newsgroup is accessed via NNTP
servers (even using Google Groups, the back-end is NNTP), and NNTP servers
do not generally display submitted posts immediately. Depending on the
server and the current load, a post could take minutes or even hours to show
up. With direct access to the NNTP server, hours is pretty rare, but Google
doesn't provide you with direct access to the NNTP server and I've noticed
it can take longer for posts to show up there.
Patience is a virtue.
Yes, it shows in green. I've replicated my infinite loop just to test
this out. So, this main thread is just not doing anything (other than
handling UI info in the message loop that we cannot see), which is why
it shows on Application.Run, which is the lowest part of the call
stack for this main UI thread. Did I get it right?
Depending on the code you've written for the main form, it's possible to
manage to break just at the right moment when your code for that form is
executing. In that case, the debugger would show your execution location in
yellow at the actual point of execution.
Of course, if you set a break point or call the "debug break" method
explicitly in the main form's code, then you are assured of breaking in that
main thread, in the code you've written.
Also, it's not really so much that the call to Application.Run() is the
"lowest part of the call stack" for that thread. It just happens to be the
lowest part that is in *your* code. The thread is actually executing deeper
down than that, which is in fact why the location is green rather than
yellow. If you had the source and a PDB for the code that was executing (in
the system code in this case), the debugger would have shown you that code
(and it will when the code happens to be your own, since in that case you
*do* have the source and a PDB for it).
Oh, I was under the impression that the others continued. How about
socket threads that are made from using Sockets? They must stop as
well, right?
Yes, every thread in the process stops. A corallary to this is that when
you use a "step" command in the debugger, every thread gets to run as well
*but* you only get to control line-by-line the thread you're looking at.
This can produce some challenging "debugging-only" scenarios in buggy
multi-threaded code.
Pete