|
Paul Riley wrote:
it finishes whatever it's doing first.
Correct, more specifically it will run until it gets to a safe place to throw the exception. In this case it waits until it is done running unmanaged code before throwing the exception (Thread.Sleep is actually a P/Invoke'd call to the OS, judging by ildasm output).
James
Sig code stolen from David Wulff
|
|
|
|
|
not exactly,thread.Abort() never worked.
you can try this:
workthread()
{
while(true)
{
Console.WriteLine("thread will sleep");
System.Threading.Thread.Sleep(50000);
Console.WriteLine("thread is awake");
}
}
and after you called thread.Abort() and exit the application,the thread never stop.
Is that to say,abort() will never find a safe place to throw a exception????
lost my way
|
|
|
|
|
This code works for me
save as ThreadAbort.cs, compile with csc /out:ThreadAbort.exe /target:exe ThreadAbort.cs
Even better, if you have VS.NET you can watch the output window and it will tell you when the thread has exited.
using System;
using System.Threading;
namespace ThreadAbort
{
class Class1
{
[STAThread]
static void Main(string[] args)
{
Thread f = new Thread(new ThreadStart(Run));
f.Start();
Thread.Sleep(1500);
f.Abort();
Console.ReadLine();
}
static void Run()
{
while(true)
{
Console.WriteLine("thread will sleep");
System.Threading.Thread.Sleep(2000);
Console.WriteLine("thread is awake");
}
}
}
}
James
Sig code stolen from David Wulff
|
|
|
|
|
yes it can abort a sleep thread,but...............?
maybe my code have some logical error.
thanks whatever!!!!!!!!!
lost my way
|
|
|
|
|
Thread.Abort() does work...its just fickle. Its also pretty much required that you catch the ThreadAbortException that Thread.Abort() throws. Its also a good idea to call Thread.Join() immediately after your call to Thread.Abort(). Thread.Join() will cause the calling thread to wait indefinitely until the child thread terminates. If you do not put Thread.Join() in, the application can exit before the child thread does, in which case the child thread will most likely never exit. The reason for this is the application repeatedly fires off the ThreadAbortException until its actully caught and dealt with. When the application exits, the ThreadAbortException can no longer be thrown, resulting in a dead thread that won't go away. I tried this, and it seemed to work fine (I tried 5 times, properly exited every time):
using System;
using System.Threading;
namespace TestThreadAbort
{
class TheTest
{
[STAThread]
static void Main(string[] args)
{
Console.WriteLine("[M] Starting worker thread.");
Thread t = new Thread(new ThreadStart(WorkerThread));
t.Start();
Thread.Sleep(170000);
Console.WriteLine("[M] Killing WorkerThread...");
t.Abort();
Console.WriteLine("[M] Main thread waiting...");
t.Join();
Console.WriteLine("[M] Goodbye.");
}
private static void WorkerThread()
{
try
{
while (true)
{
Console.WriteLine("[W] WorkerThread saying hello.");
Thread.Sleep(50000);
}
}
catch (ThreadAbortException)
{
Console.WriteLine("[W] WorkerThread saying bye-bye.");
}
}
}
}
|
|
|
|
|
Jon Rista wrote:
The reason for this is the application repeatedly fires off the ThreadAbortException until its actully caught and dealt with.
On the contrary, you cannot fully catch the ThreadAbortException. Once execution has exited the catch block, the CLR will continue to rethrow the exception until: 1) Thread.ResetAbort is called which cancels the request to destroy the thread or 2) All of the finally blocks have exited, allowing the thread to die.
James
Sig code stolen from David Wulff
|
|
|
|
|
When I made new windows service solutions, it's notice that "VC not found or has not registered". Please help me how can I solve this problem.
My .NET is Enterprise Architect. Please mail me
Thanks
Duc Phuoc
Email : il9u@yahoo.com
|
|
|
|
|
hi,
i have a problem with modeless forms...
When i click a button and execute the code below it works...
OnClickButton()
{
..
FormX MyForm=new FormX();
MyForm.Show(); // it creates a modeless form as expected!..
..
}
but when i call these two lines of code in another function such as a CallBack function like OnReceiveAsync() in my Client program or in a timer delegate function like Timer_Elapsed() it doesn't works...
it tries to create MyForm but it does not properly appears and it locks the whole program..
is it a bug? or should i do something else for Modeless forms & dialogs..
Please try it your self and see what happens..
Modal forms (MyForm.ShowDialog();)
works properly everywhere whether called by clicking on buttons or
calling via another function
but why modeless are not?..
Thanks for ur help...
just listening to you...
|
|
|
|
|
|
Thanks Daniel..,
it works now with ur help,
here what i did...
maybe it helps for others...
Whisper.ShowMessage(); // i put this line it instead of two commented out
lines below;
//Whisper NowWhisper=new Whisper();
//NowWhisper.Show();
protected static Whisper NowWhispering;
public static void ShowMessage()
{
NowWhispering=new Whisper();
Thread t=new Thread(new ThreadStart(NowWhispering.MyShow));
t.Start();
}
protected void MyShow()
{
Show();
while(NowWhispering!=null)
Application.DoEvents(); // i think this line protects locking..!
}
just listening to you...
|
|
|
|
|
can anyone help me out with the coding conventions that are recommended for .NET users.....as i would be recommended by micorsoft!
and a little bit of detail would be appreciated specially about naming controls...for example a textbox!
thanks!
|
|
|
|
|
rule number one : no more than one exception per line.
How low can you go ? (enculage MS)
|
|
|
|
|
|
i have read all that...its inconclusive...
as i said i want concrete information what is the best way to name a control....there is no such description of controls on the msdn article....can you help me out with something else?
|
|
|
|
|
|
well when i mean control imean the controls as textbox and label how do you name these kind of controls in .net....do we use the hungarian notation or the new camel or pascal notations?
so what do you think?
|
|
|
|
|
At the moment I'm still using Hungarian for controls, while following the naming guidelines for everything else. Most code I've seen that tries to follow the guidelines adopts a similar approach. Some also still use Hungarian for fields, e.g, using a leading _ or m_.
To be consistent I guess we should really just use the full name of the control in camel case, e.g., customerTextBox, customerLabel rather than txtCustomer, lblCustomer, etc.
Kevin
Kevin
|
|
|
|
|
can you send me the list of al lthe hungarian notation list .... i am still confused about what to apply in my project and can you tell me whom or where i can put this question as well...
thanks
|
|
|
|
|
I've asked thsi question myself before and never got an answer. I don't know offhand where to find the Hungarian list (for controls). But, if you look under Visual Basic coding conventions for VB6 in the VS help or at the MSDN Library site you should find there is a list of this sort.
Kevin
|
|
|
|
|
If the automatically assigned control names VS.NET provides are anything to go by, you would use camel casing with a unique identifier at the end, e.g.:
System.Windows.Forms.TextBox textBox1;
System.Windows.Forms.TextBox textBoxUserName;
This is the way I do it in .net, simply because it's the way the IDE does it, and I'd hope the IDE follows the accepted conventions
|
|
|
|
|
To get the hungarian notation list:
Run VB6
Pull up Help
Goto Index (or is it Search) and enter 'Naming Conventions'
This should point you to the Naming Conventions page which contains Hungarian Notation for all variables, forms, controls, etc.
In our group, we have chosen to move completely to the naming conventions specified in the CLS. So everything, private or public, follows the CLS nameing standards. Methods, classes and namespaces are Proper Case. Parameters, properties, variables are camelCased. I believe that the only exceptions we have made so far are with the rare fat client code and the form itself is still named frmFormName.
---------------------------------------------
Once I thought I was wrong but I was happy to discover that was a mistake.
Condor
|
|
|
|
|
so your using the camel and pascal notations but tell me what are you using for controls?
hungarian?
if not then tell me what notation are you using for controls and give me some examples too...
thanks!
|
|
|
|
|
Looking through my code, I have turned to using pascal notation for all of my controls. So for example, most pages I build has a line for display of error messages. That label is named ErrorMessage. A combobox which allows the choices for descriptions of a project phase is named ProjectPhaseChoices. It also helps clarify the code a little bit. For example:
lifeCycle += 2; vs.
LifeCycleChoice.SelectedItem = 1;
It is obvious which is a variable. If Microsoft allowed the original notation for controls (eg: LifeCycleChoice="Unit Testing"; ) you would have a real hard time short of mouse-floating to determine if you are working with a control or an internal variable. Fortunately, you are forced into explicitely naming the property within the control object. But it is all a matter of personal choice. I name all of my objects in Pascal, so it makes sense that the controls also be named in Pascal as well since both are just objects.
---------------------------------------------
Once I thought I was wrong but I was happy to discover that was a mistake.
Condor
|
|
|
|
|
I just type whatever comes to mind first If I remeber to keep the shift in, it capitalizes, else all variables (aka objects, controls, instances) stay lowercase. Intellisense does the rest.
"There are no stupid question's, just stupid people."
|
|
|
|
|
leppie wrote:
I just type whatever comes to mind first
At times I think that is one of the best ways to do it. Not because it makes code any more readable (it doesn't) but because of C# having the ^#*&^@( case sensitivity. So frequently I screw up a namespace or object reference because of case. Very frustrating. But at the same time, is doing code in all lower case any different from the original mainframe days when code was all upper case??????
---------------------------------------------
Once I thought I was wrong but I was happy to discover that was a mistake.
Condor
|
|
|
|