|
Use the return statement.
|
|
|
|
|
I'm not sure how the 'return' statement can help you...
No, to do this, what you need to do is move the try/catch into the loop, or add a try/catch within the loop, so the catch exits within the loop and the loop can continue.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Oops. I was thinking of another language, sorry about that. Stick to the professional.
|
|
|
|
|
You have to put the statements inside the inner while loop also inside a try/catch block.
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
Does anyone know of a good 3rd party .net reporting package? I tried using the crystal reports package included with visual studio, but the software doesn't let the user enter information directly onto a generated report. If anybody knows a good one, please let me know.
thanks
Brian
|
|
|
|
|
I have some problem about FileSystemWatch
I use FileSystemWatch to monitor the dir "D:\\TEMP"
And I want to create a file in the dir "D:\\TEMP" , so path="D:\\TEMP\\test.xml"
Then It's fail when I create the File in the dir by using FileStream
And It's fail when I copy the File to the dir by using File.Move();
It's very unreasonable. =.=
My program is below ..
-------------------------------------------------------------------------
//*** Program Slice 1
public string Path = "D:\\TEMP";
//*** Program Slice 2
//*** Create FileSystemWatcher
FSWatcher1 = new System.IO.FileSystemWatcher();
FSWatcher1.Path = Path;
FSWatcher1.IncludeSubdirectories = false;
FSWatcher1.EnableRaisingEvents = true;
FSWatcher1.Created += new System.IO.FileSystemEventHandler(FSWatcher1_Created);
//*** Program Slice 3
//*** Trigger when File is Created
private void FSWatcher1_Created(object sender, System.IO.FileSystemEventArgs e)
{
//*** do something
Debug.WriteLine("〔"+e.Name+">〔"+e.FullPath+">〔"+sender.ToString()+ ">");
}
//*** Program Slice 4
//*** I found that the file is created in the dir ,
//*** but when it execute the line "m_streamWriter.Close();" , the file created is gone
FileStream fs = new FileStream(Path , FileMode.Create , FileAccess.Write);
StreamWriter m_streamWriter = new StreamWriter(fs , Big5);
m_streamWriter.BaseStream.Seek(0, SeekOrigin.End);
m_streamWriter.Write(Result);
m_streamWriter.Flush();
m_streamWriter.Close();
//*** Program Slice 5
//*** Then I use the method File.Move , It's still fail
File.Delete(Path);
File.Copy(Path_Temp , Path);
-- modified at 4:07 Wednesday 7th September, 2005
|
|
|
|
|
The FileSystemWatcher won't prevent you from creating files in the watched directory. There's got to be something else that's preventing you from doing this. A Permissions issue, perhaps?
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Hi Everyone,
I would like to know how i go about changing a parent form from a child form.
For example from the main menu click search, it pops up you choose search for client, you notice the client doesnt exist so you click a button marked "Add New" it should then close the pop-up form and change the main menu form to the client details form, loading a blank record.
Any help would be fantastic, even a push in the right direction.
Cheers.
Paul
|
|
|
|
|
In C#, what you need to do is use delegates. These are basically function pointers, you set them up in the dialog, and define them when you create the dialog to be a method in the main form. Then the main form gets a callback event when ( for example ) the Add New button is pushed, and can respond however it likes.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
I am fairly new to C# and I am building an application that has multiple forms. Initially my application consumes 1 mb of memory. Then as I open forms the amount of memory increases to several mb. When I close the forms the memory is not released. If I reopen the same form the memory does not increase proportionally. But it keeps increasing. How can I make sure that the memory is released?
|
|
|
|
|
How do you know whether the memory is released or not? What analysis tools are you using? Are you using task manager for your analysis? It is probably not the most granular and accurate method to make these kinds of determinations, because the CLR may keep the memory if no other apps need it, even when you think you've "freed" it. Have you been to Jeffery Richter's class(es) on Memory Management/Garbage Collection in .NET? Have you tried CLRProfiler? Have you searched CodeProject and/or Google for "performance counters" and see how you can configure perfmon to give you more specific information about what your app is doing?
Are you really having performance problems? Is the machine is thrashing because of low memory conditions?
Matt Gerrans
|
|
|
|
|
I just use the Task Manager; for all practical purposes it seems good enough for watching what happens to memory. I have used bounds checkers for memory leaks. There are no "reported" memory issues. I do not have thrasing or any issues "yet". I pretty much have read "Just trust GC". But when a class/form is disposed is not really disposed? Are the contained controls disposed? The application is reading data files.
|
|
|
|
|
VickyC# wrote:
for all practical purposes it seems good enough for watching what happens to memory
The Task Manager is actually lousy at showing what's really going on inside the virtual machine that is the managed execution environment of the .NET Framework.
What you're seeing in Task Manager is the amount of memory reserved for the entire virtual machine that you application runs in, not just your application code.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
I do not disagree with this part.
Anyhow thanks for the tips.
|
|
|
|
|
Not only that, but you'll see this same phenomenon with unmanaged apps, where you allocate memory, then free it, but Task Manager does not show you going back to the original amount. If you don't believe me, write yourself a little C++ app that allocates a few meg on the click of a button and frees it on another click and watch in Task Manager. So, it is not only the CLR that does this thing of not fully releasing dereferenced memory, but also the OS itself. That is because they both have the expecatation that an app will probably repeat its past behavior, so why waste all the extra cycles completely releasing the memory, then going to reallocate it a short time later. If that memory really is not used by the app again and other apps need it, that more complete deallocation will take place.
You can use the SetProcessWorkingSetSize() API function to hurry up and "collect" the the memory that your app has released. I had an app that would use a few meg of memory infrequently and got some complaints that it was taking up too much memory (people looking at Task Manager); I added a call to SetProcessWorkingSetSize() right before it went into its "background" mode and it showed up quite tiny in Task Manager (I forget the exact numbers, but it went from several meg, to a few K). Keep in mind though, that this is only for cosmetic purposes and doesn't really make your app use memory more efficiently or anything like that (and in fact may make your app perform worse, since when it does try to use that memory again, it will probably be slower in getting it).
Matt Gerrans
|
|
|
|
|
If you are just using Task Manager, minimize your application and see the memory usage decrease drastically (in one of my apps, from around 25 MB to just over 2).
But as others have said, for a .NET app this number is not real.
-- LuisR
Luis Alonso Ramos
Intelectix - Chihuahua, Mexico
Not much here: My CP Blog!
The amount of sleep the average person needs is five more minutes. -- Vikram A Punathambekar, Aug. 11, 2005
|
|
|
|
|
VickyC# wrote:
How can I make sure that the memory is released?
The garbage collector will always release the memory, it's just a question of how long it takes to do so. So long as you've not used any disposable objects and failed to dispose of them, it's a waste of time trying to track memory usage, the framework will collect the objects eventually, and any attempts to mess with it will be counter productive.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Can I force it to release faster?
|
|
|
|
|
Short answer Gc.Collect;. Long answer - don't. The framework has been optimised already, fighting it like this will only hurt performance.
What's the issue, are you running out of memory ?
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Right now I am not running out of memory. But when the code will go into production I am sure that I will have a high risk to run out of memory.
|
|
|
|
|
VickyC# wrote:
But when the code will go into production I am sure that I will have a high risk to run out of memory.
From opening a few forms ? What's on them ? If it's bitmaps, make sure you dispose of them. If they are just normal forms, are you expecting to run on machines with < 64 MB of memory ?
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Well here is the pattern, it just keeps tagging some memory and then at some point memory is released but it never reaches the initial amount. So when the app will run for an extendend period of time it seems that I will have an issue. Yes, my question is when a form is disposed do all the children get disposed? Or I need to dispose each one.
|
|
|
|
|
VickyC# wrote:
Well here is the pattern, it just keeps tagging some memory and then at some point memory is released but it never reaches the initial amount. So when the app will run for an extendend period of time it seems that I will have an issue.
You cannot run out of memory, because if things get to a critical level, the framework will force a collectitself. It will also perform a collect periodically. Any objects that are not used for long are quickly cleaned up. Objects that are used for a long time are cached for a long time, which is what you're fighting when you force the collection yourself.
VickyC# wrote:
Yes, my question is when a form is disposed do all the children get disposed? Or I need to dispose each one.
You don't need to dispose of any forms. You only need to dispose of resources such as bitmaps. But yes, if there is an object tree and the object impliments IDisposable, the dispose method should clean all of it.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
|
Christian Graus wrote:
You don't need to dispose of any forms.
Not entirely true. If you call .ShowDialog() on any form, you have to .Dispose() it when you're done with it.
From the MSDN Gospel:
When a form is displayed as a modal dialog box, clicking the close form button (the button with an "X" at the top right of the form) causes the form to be hidden and the DialogResult property to be set to DialogResult.Cancel. Unlike modeless forms, the Close method is not called by the .NET Framework when the user clicks the close form button of a dialog box or sets the value of the DialogResult property. Instead the form is hidden and can be shown again without creating a new instance of the dialog box. Because a form displayed as a dialog box is not closed, you must call the Dispose method of the form when the form is no longer needed by your application.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|