|
Thanks Pedram Behroozi
You r right.
Actually i was developing a Windows Appl Using WPF.
in my case i need to remove this user control from memory . becoz after removing it from canvas or panel , if i try to fire some event then this Control also respond the event (Though it has been removed).
for a workaround i detached the Event Handler for user control(when i remove it from canvas/panel). but it still resides in memory and remains throughout the program execution (becoz this control is not local to any Block) thus degrading performance .
Regards
Rishi
|
|
|
|
|
Well I know nothing about WPF UserControls and unfortunately I can't help you.
I think it's better for you to ask it in WPF / WCF / WF Forum[^].
Regards
I died as a mineral and became a plant,
I died as plant and rose to animal,
I died as animal and I was Man.
Why should I fear? When was I less by dying?
-- Rumi[^]
My blog
|
|
|
|
|
It ok Pedram Behroozi
i have also posted the problem in WPF section but did't get any resonable ans.
anyways thanks.
|
|
|
|
|
Removing instances from memory is the Garbage Collector's job. You don't have much control over when that gets done. But you can do cleanups inside the Dispose method. So basically you remove your event handlers in the Dispose method, and simply calle the Dispose method when you remove your control from the panel. (Typically Dispose is called for all the controls in a Form from within the Close method of the Form).
Also if you control is hanging around in memory long after you have removed it, it could mean that you have some references to it somewhere in your program.
|
|
|
|
|
I didn't realise you were using WPF.
WPF controls don't have Dispose methods because they don't need them. WPF controls don't use any unmanaged resources.
To release the memory used by a WPF control all you have to do is make sure you have no references to it, and the garbage collector will automatically clear up all the memory next time it runs.
Events are something to watch out for. Remember that the event source holds a reference to the event sink, so yes if you have a control sinking events from a source on a main form, then you will need to make sure you detach the event handlers if you want the control to be released.
Note that the garbage collector does not immediately remove the object from memory. the GC only runs occasionally, and when there is a requirement for more memory than is available. This is normal behaviour and there is nothing wrong with it. if you want to test things you can call GC.Collect() to force a collection and see if your memory is cleared up, but you shouldn't leave this in the code when you release it. The GC is carefully balanced, and forcing unnecessary collections can really screw up it's performance.
If you are still having problems getting the object to be cleared up, you can use WinDbg and SOS to peer deeper into the objects on the heap and work out why they aren't being collected. (Getting started with WinDbg & SOS[^],
How to find a GC leak[^], Memory leak detection in .Net[^])
Simon
|
|
|
|
|
Thanks Simon 
|
|
|
|
|
Hello,
Are there side effects of setting Socket.ReceiveBufferSize to a large value (e.g. 50 MB)?
I am writing an application to receive and process a large amount of data. Instead of writing code to read data asynchronously, I was thinking of setting Socket.ReceiveBufferSize to a large number. I am not worried about consuming system resources since the program will run on a dedicated machine. However, I am not sure whether this might have a negative effect over performance, or any other side effects that I should take care of.
FWIW, my application simply uses StreamReader.ReadLine() over the socket's network stream.
Thanks a lot
|
|
|
|
|
What do you hope to gain by setting the receive buffer size that large?
Even if the system lets you do it, it will most likely hurt performance.
Why not try it and see what happens?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
By setting the receive buffer so large, I am hoping to avoid having to read data in a thread and process it in another one. At certain (and few) instances of time, I will be receiving 3X data, where X is the amount of data I can process per second. However, right following that, there will be 0.1X data for some time. So, instead of having to synchronize reader and processor threads, I was hoping the system buffer could just hold the additional data for me.
Meanwhile, I don't think I can test performance right now, because there are many other factors that I might not be able to control. So, why do you think it would hurt performance?
Thanks for your help.
|
|
|
|
|
AFAIK, Windows Sockets will let you set it to a max size of 1MB.
The receive buffer isn't meant to be a data store.
For best TCP/IP performance, your user-mode code should remove ("receive")
data from the socket ASAP. i.e. Send buffer should be full, receive buffer should
be empty.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
hello,
Do someone know an algorithm for generating a smard card numbers composed from 14 numbers
best regards
dghdfghdfghdfghdgh
|
|
|
|
|
I have a TcpClient connection that connects to a local java process. When I close the form, I call dispose on my tcp client handler and kill the java process. However, this is causing the below error:
11:22:01 TcpClientHandler.Read; IOException: System.IO.IOException: Unable to read data from the transport connection: A blocking operation was interrupted by a call to WSACancelBlockingCall. ---> System.Net.Sockets.SocketException: A blocking operation was interrupted by a call to WSACancelBlockingCall
>>>> at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
>>>> at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
>>>> --- End of inner exception stack trace ---
>>>> at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
>>>> at System.IO.StreamReader.ReadBuffer()
>>>> at System.IO.StreamReader.ReadLine()
I am a bit confused as to why this error is being thrown, since when I close the form, the "Reading..." trace is never printed out.
public void Read()
{
Trace.WriteLine("##debug: Reading...", "INFORMATION");
try
{
do
{
_alertMessage = _reader.ReadLine();
if (!string.IsNullOrEmpty(_alertMessage))
{
if (MessageReadEvent != null)
MessageReadEvent(this, _alertMessage);
}
}
while (!string.IsNullOrEmpty(_alertMessage));
}
catch (IOException io)
{
Trace.WriteLine(MethodBase.GetCurrentMethod().DeclaringType.Name + "." + MethodInfo.GetCurrentMethod().Name +
"; IOException: " + io.ToString(), "ERROR");
}
}
When I dispose of the tcp client handler I dispose of the reader, and then call tcpClient.Close();
Regards,
Gareth.
(FKA gareth111)
|
|
|
|
|
Gareth H wrote: and then call tcpClient.Close();
No way to say this doesn't get people upset but, developing quality software can ONLY be accomplished by reading the documentation, period.
link[^]
When you are finished sending and receiving data, use the Shutdown method to disable the Socket. After calling Shutdown, call the Close method to release all resources associated with the Socket.
Gareth H wrote: I am a bit confused as to why this error is being thrown, since when I close the form, the "Reading..." trace is never printed out.
I can't explain how your code works. A wild guess is that it did print out long before you closed anything and you just are not seeing it because you are mistakenly expecting to see it print out when you close the form. That said, an exception will be thrown from a blocking read when the read is canceled. That behavior is by design.
led mike
|
|
|
|
|
I added the Shutdown call, but that didn't solve the problem. It seems that the exception is thrown the same number of times a message is sent to the java process. So, if I send 5 messages, 5 exceptions are thrown when the form is closed.
Regards,
Gareth.
(FKA gareth111)
|
|
|
|
|
Gareth H wrote: I added the Shutdown call, but that didn't solve the problem.
Did you read my post? 
led mike wrote: That said, an exception will be thrown from a blocking read when the read is canceled. That behavior is by design.
Gareth H wrote: It seems that the exception is thrown the same number of times a message is sent to the java process.
Without being able to reproduce the behavior themselves it is unlikely anyone will be able to help you. I have done socket development since 1994 and I have never seen anything such as you describe. My first guess is that the behavior is introduced by your code, not by the TCP stack or the any of the other libraries you are using.
Some of what you previously said indicates you are using threads. It is very likely you are creating a new reading thread for each message sent to the Java process since that would explain the behavior.
led mike
|
|
|
|
|
I solved the problem. Changed my Read() method to create a StreamReader in a using block.
Regards,
Gareth.
(FKA gareth111)
|
|
|
|
|
I need to capture the SessionEnding event in my C# app, this worked fine by adding a handler to the SystemEvents.SessionEnding event when I had message loop on my main thread. Unfortunately that is now not the case, I no longer have a message loop and now I don't get the notification.
I have tried creating a message-only window to capture the WM_ENDSESSION/WM_QUERYENDSESSION messages but these are only sent to top-level windows and not message-only windows. So I tried using SetWindowsHookEx to hook WH_CALLWNDPROC which still does not send the WM_ENDSESSION message, then I tried SetConsoleCtrlHandler which also doesn't seem to work.
Does anyone have any ideas on how I can trap this message without a main form?
Thanks.
|
|
|
|
|
Replaces "[fieldname]" in the HTML template document with data from the corresponding column of the SQLite table
|
|
|
|
|
What you are saying is not a question. I don't understand what you are trying to do.
Simon
|
|
|
|
|
Don't care.
He's just getting on everyone's nerves, posting the same crap again and again.
He's trying to find some idiot who will do his work.
Regards
Thomas
www.thomas-weller.de
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
|
|
|
|
|
Use VS 2005.NET
Create Windows Form Application
|
|
|
|
|
The more times you post the same post the less chance you have to get an answer especially when what you are posting is homework.
|
|
|
|
|
Uhhh What do you really mean ?
Explain your problem
Vuyiswa Maseko,
Sorrow is Better than Laughter, it may Sadden your Face, but It sharpens your Understanding
VB.NET/SQL7/2000/2005
http://vuyiswamb.007ihost.com
http://Ecadre.007ihost.com
vuyiswam@tshwane.gov.za
|
|
|
|
|
Stop cross posting your homework everywhere.
Bob
Ashfield Consultants Ltd
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
