|
1) Do you catch the ThreadAbortException in a loop like that?
try{<br />
for(...){<br />
try{<br />
<br />
}catch{ ... }<br />
}<br />
}catch(ThreadAbortException){ ... }
Then the thread can run for hours without doing anything.
2) You can stop the thread a clean way. Declare a boolean variable, and check it's value in the thread method:
bool threadStopped = false;<br />
...<br />
private void myThreadMethod(){<br />
doSomething();<br />
if(stopped){ return; }<br />
doSomethingElse();<br />
if(stopped){ return; }<br />
doAnything();<br />
if(stopped){ return; }<br />
...<br />
}
With that stop-variable you don't need Thread.Abort() and the try/catch stuff, because the thread stops when you set threadStopped = true.
|
|
|
|
|
I did not catch the ThreadAbortException in a loop and the execution of the tread is actually stoped.
There's still one problem with your codes: what if I want the tread to stop immediately when it is "doing something"?
|
|
|
|
|
Which is better code?
public object GetValue(Hashtable hashtable, object key)
{
if(hashTable == null)throw new ArgumentNullExeption("hashTable");
return hashtable[key];
}
or
public object GetValue(Hashtable hashtable, object key)
{
return hashtable[key];
}
Clearly the second example will throw anyway if the passed hashtable is null.
The first is more explicit if less concise. Is there any difference otherwise?
Any feedback would be appreciated.
Robert Zurer
|
|
|
|
|
For my opinion, the first is getter, you will get a cleaner error message. You should test key also.
If you have fear of the perf hit of such test you can use Debug.Assert from System.Diagnostics
Jonathan de Halleux.
www.dotnetwiki.org
|
|
|
|
|
Thank you for your response, (and also for your fine articles).
As to using Debug.Assert, I want the exception to be thrown.
(As to testing key, I may want to return null and let the caller handle that, but this is just a test example anyway.)
Am I right in assuming that the performance hit you are referring to is not the statement
if([ErrorCondition])
but the actual exception which will be thrown?
In that case, the exception would be thrown only once in either case, resulting in equal perfomance hits. Or have I missed something?
Thanks again.
Robert Zurer
|
|
|
|
|
bzurer wrote:
In that case, the exception would be thrown only once in either case, resulting in equal perfomance hits. Or have I missed something?
Totally right, anyway, to my opinion, it is always worth the price to check parameters: write such tests and documented it.
Jonathan de Halleux.
www.dotnetwiki.org
|
|
|
|
|
Thanks for you response, (and also for your fine articles).
I want to throw the exception so Debug.Assert wouldn't work here.
I assume that the perfomance hit you are talking about is the actual exception and not the if statement. If I haven't misunderstood, wouldn't one exception be thrown in either case resulting in equal performance hits?
Robert Zurer
|
|
|
|
|
IMO, throw the ArgumentNullException. If you don't, the CLR will throw a NullReferenceException, and those are always annoying because any reference Type throughout the executing code could be null and you'll have to debug to find out which. Throwing the ArgumentNullException exception should make it obvious. Either way, the calling code should catch the exception and display a user-friendly error (though in this example, there's no excuse for an exception being thrown in a release app).
In the base class library assemblies, any params that shouldn't be null are checked in this manner.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Is it possible to have a propety as an array? If so, how do I access it??
I usually create my properties in this manner
class Object{
private string sProperty;
public string Property{
get{return sProperty;}
set{sProperty = value;}
}
Can I do the following, and how do I properly access the array
class Object{
private string[] sProperty;
public string[] Property{
get{return sProperty;}
set{sProperty = value;}
}
|
|
|
|
|
I don't know about string[], but if you use ArrayList like:
private ArrayList alBtnCommands = new ArrayList();
public ArrayList ButtonCommands
{
get
{
return alBtnCommands;
}
set
{
alBtnCommands = value;
}
}
then you can call it by:
currentButton.ButtonCommands.Add(AnItem);
currentButton.ButtonCommands.RemoveAt(i); // i(integer) is an index
SomeThing = currentButton.ButtonCommands[i];
currentButton.ButtonCommands[i] = SomeThing;
It's not what you asked for, but it might be similar for string[]
Hope it helps
Thomas
|
|
|
|
|
Using an IList implementation like the ArrayList isn't always the answer. An array is fixed. Items can't be added or removed. This is often necessary in cases like returning the fonts installed on the system, or returning the printers installed on the system. In these cases, though, the property is read only (only implements the get accessor). If it was a list, developers can easily modify it (without even instantiating a new one) which might corrupt the behavior of the object.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Do it just like you wrote :
<br />
public string[] Property{ <br />
get{return sProperty;}<br />
set{sProperty = value;}<br />
}<br />
and access it like so
<br />
Object o = new Object();<br />
o.Property = new String[] {"foo", "bar"};<br />
Console.WriteLine("{0} {1}", o.Property[0], o.Property[1]);<br />
another trick is to use default properties[^]
write you property like this
<br />
public string this[int index] {<br />
get { return sProperty[index]; }<br />
set { sProperty[index] = value; }<br />
}<br />
and access like this
<br />
Object o = new Object();<br />
o.Property = new String[2];<br />
o[0] = "foo";<br />
o[1] = "bar";<br />
Console.WriteLine("{0} {1}", o[0], o[1]);
HTH
The smaller the mind the greater the conceit.
Aesop
|
|
|
|
|
The cop (FxCop) says do not return array as properties...
Jonathan de Halleux.
www.dotnetwiki.org
|
|
|
|
|
Funny, the Cop didnt seem to have a problem with the little snippet I compiled 
But if they're the rules fair enough.
Cheers for the info.
The smaller the mind the greater the conceit.
Aesop
|
|
|
|
|
Thanx - this is exactly what I needed.
I only need it because I'm converting some VB code and it does it this way.
What is the FxCop mentioned?
|
|
|
|
|
|
i have an application which has a 2 MB .exe. but when it runs it uses the 21 MB of the primary memory. Before initialization of the forms it already uses 13-14 MB (in release mode).after main form loaded it bocomes 21 MB. Because i use dynamic binding when using class i don not think that it is because all project loding at start up. i think it is because of .net framework loads itself before. have any idea how can we decrease this use amount?
|
|
|
|
|
Of course the .NET Framework is loaded before your app! What do you think managed your managed code? This is a runtime, just like Java required a JRE, VB requires the VB Virtual Machine (VM), etc. The CLR will take a few megs but the assemblies that are loaded into your application will take as much space as required to execute the code. The CLR JIT's only what is linked as it executes code, so it all isn't JIT'd at once (JIT-on-demand). In fact, an unmanaged AppDomain is created that loads the CLR and creates a managed AppDomain, then your executable is loaded into that AppDomain along with any dependent assemblies. It has to be loaded first or your application doesn't run.
How can you reduce memory? For once, implement a clean design. Close handles, dispose disposable objects, dispose modal forms (when you call ShowDialog) when you're finished with them. Use structs (allocated on the stack instead of the heap) when you need information on a short-lived duration (like a System.Windows.Forms.Message is used only for the current message, so there's no need to allocate it on the heap). All the things that computers science (or experience) should teach you.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Is it possible that in future releases of Windows, the CLR would be started as system starts and manage all dotNET applications? It seems that currently every single dotNET app loads a copy of the CLR into memory even when they are executed concurrently
|
|
|
|
|
The CLR would be started with various system components in "Longhorn", but that won't change your program's behavior. The CLR - the runtime for managed code - is loaded for each app. This - like all runtimes - helps protect the other programs using the runtime and the operating system as well from each other. If your program was to crash and tear down the CLR, I definitely don't want it taking down mine or crashing the OS. This can even be done without crashing - a call to Environment.Exit unloads the CLR and quits the application immediately, regardless of any running threads.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
I need to go to another form in my project. I need that the main form will close when I press a button to go to the second form. I can't use Application.Exit because than the second form closes too.
please help!!!!
|
|
|
|
|
Can you temporarily hide the main form?
What a piece of work is man, how noble in reason, how infinite in faculties, in form and moving how express and admirable . . . and yet to me, what is this quintessence of dust? -- Hamlet, Act II, Scene ii.
|
|
|
|
|
Every form you create acts just like a class would so you could just do.
MySecondForm form = new MySecondForm();
form.Show();
this.Dispose();
The 'this' keyword refers to the object you're form is derived from including all of the custom objects
and functions you have put in. You could also just say 'Dispose();' instead of 'this.Dispose();' but
for keeping clarity it's better to use the this keyword.
You could also say 'this.Hide();' but then it keeps that form in memory which when you're dealing
with multiple forms this could eat up your memory pretty quickly. I just take my forms out of
memory when I don't need them.
------------------
I'm naked under my clothes...
|
|
|
|
|
this.Dispose(); doesn't work for me. it still closes the whole application. the this.Hide works and altought I'm making a small program a slow computer is gonna run it so if you can recommend me of somthimg else that will allow me to save in memory usage please find me somthing that doesn't just hides the window but thanks anyway.
Modyfied: I just realized I don't need to close the main form and that the this.Dispose works for my other forms. anyway thanks alot you've been a great help for me. see ya later
|
|
|
|
|
You can't dispose the main form because that's what the message pump (which Application.Run starts) waits for. If you dispose the main form, you effectively let the message pump know that it can quit and your entry point returns. When the entry point returns, the CLR unloads your application (if there are no running background threads).
See Charlie's response for a good solution (no need to repeat it).
Also, you might consider a wizard-like interface, even if it has no "Back" or "Previous" button. You load one Form which adds and removes instances of container classes (like the Panel) onto its surface. This is how property sheets and wizards (which actually use the same interfaces and functions) work in Windows Explorer and other applications that use the shell-provided property sheet implementation.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
