|
you kick off the receiving actions outside the callback once, then continue the process by issuing another receive inside the callback until you had enough. And length holds the amount still to be received, so once you got it all, you don't issue a new beginreceive, so the callback isn't called any more, the only time it is called with length zero is at the start of a conversation.
|
|
|
|
|
Ah yeah I got it now. Luc I just want to thank you for your help. Here is what I have now and it seems to be working well:
int bytesRead = handler.EndReceive(iar);
if (bytesRead > 0)
{
if (state.Length == 0)
{
state.Length = BitConverter.ToInt32(state.buffer, 0);
Logging.Log(handler.RemoteEndPoint.ToString() + " is about to send " + state.Length.ToString() + " bytes", true);
handler.BeginReceive(state.buffer, 0, StateObject.BufferSize, 0,
new AsyncCallback(ReadCallback), state);
}
else
{
state.Length -= bytesRead;
state.ms.Write(state.buffer, 0, bytesRead);
if (state.Length > 0)
handler.BeginReceive(state.buffer, 0, StateObject.BufferSize, 0,
new AsyncCallback(ReadCallback), state);
else
{
Logging.Log("Finished receiving " + state.ms.Length.ToString() + " bytes from " +
handler.RemoteEndPoint.ToString(), true);
state.ms.Seek(0, SeekOrigin.Begin);
IFormatter formatter = new BinaryFormatter();
object receivedObject = null;
try
{
receivedObject = formatter.Deserialize(state.ms);
|
|
|
|
|
Hi Jacob,
you're welcome. Glad you got it working reliably.
BTW: You could still reduce your code by sharing the read-more stuff, look again at my pseudo-code[^].
|
|
|
|
|
I had posted a question a while ago that asked how I could destroy an object in a windows program (the Flash player) and recreate it because there's a memory leak in the player. It's not huge but if you leave it around long enough it eventually will kill the system.
I got a response that said to put the player in a different application domain. Could somebody explain that please? I've read up on application domains and don't see how I would be able to use it.
What about putting a window in a different process and then have it display the flash. When it's done, it could close the window and kill itself. (at least I think I could do that.) Would that solve the memory leak?
TIA - Jeff.
|
|
|
|
|
why didn't you ask in the thread where you got the advice, so that person (my bet is on Pete) could get a notification e-mail and reply right away?
|
|
|
|
|
I went searching for it and couldn't find it. I am not sure if I asked it here or in the Microsoft forums.
J.
|
|
|
|
|
|
jbradshaw wrote: So if you are going to respond ...
I won't, however I will try and learn from any replies you'll get.
|
|
|
|
|
Luc Pattyn wrote: so that person (my bet is on Pete)
How did you guess?
|
|
|
|
|
I have a memory problem, and it isn't the more common one. I did remember the original thread well, and was hoping for a rather detailed reply. I think an article is in order...
|
|
|
|
|
Luc Pattyn wrote: I did remember the original thread well, and was hoping for a rather detailed reply. I think an article is in order...
OK - I get the hint. I'll see what I can do for you.
|
|
|
|
|
Thanks. I'm looking forward already.
|
|
|
|
|
I'll be looking out for it too!
|
|
|
|
|
jbradshaw wrote: What about putting a window in a different process and then have it display the flash. When it's done, it could close the window and kill itself. (at least I think I could do that.) Would that solve the memory leak?
Exactly. That was what I was talking about. Basically you'd have a sentinel application that existed purely to create these app domains which host the application.
|
|
|
|
|
Jeff - Luc's persuaded me to write an article on this (it wouldn't be the first time), so I'll pull one together and post it here on CP. Hopefully this will demonstrate what I've been suggesting.
|
|
|
|
|
Wow! I feel so special!
Thanks for all of your help.
Jeff.
|
|
|
|
|
Hi All,
We have a web application that timesout when the user is in a textbox typing. If the user moves out of the text box however, the timeout period appears to be reset. Is there a way to prevent the web application timing out (reset the timeout period) when the is typing in a textbox?
Our users access the web application using IE.
Thank you,
Mel
|
|
|
|
|
What kind of timeout? Is it a session timeout? What is your code doing when the user moves out of the textbox?
|
|
|
|
|
Yes, this is a session timeout.
There is no code that states if the user moves from one field to another, restart the timeout session time.
If I understand correctly this is the default behaviour of a session. Please correct me if I'm wrong. Any advice/help would really be appreciated.
Thank you,
Mel
|
|
|
|
|
Maybe someone knows of a way to renew the session on keystroke within a textbox?
Thanks
|
|
|
|
|
That would take a roundtrip to the server and a refresh of the page. The default session timeout for IIS is, I believe, 20 minutes.
I think a better solution would be to create a very small frame in your page that refreshes itself every 15 minutes or just short of whatever your session timeout is.
|
|
|
|
|
Dave, thank you for your reply.
Are you suggesting I put a frame in the page and then within the frame put the textbox? Would I then be able to refresh the page through the frame when a character is entered in the textbox, therefore refreshing the session on keystroke?
The reason for this is that I want the session to expire if the user has no interaction for a period of time, but if there is activity including text entered in the textbox then I want the session renewed.
Thank you,
Mel
|
|
|
|
|
MWRivera wrote: Are you suggesting I put a frame in the page and then within the frame put the textbox? Would I then be able to refresh the page through the frame when a character is entered in the textbox, therefore refreshing the session on keystroke?
No, I'm not saying that.
I'm saying that you leave the Textbox where it is, not caring ANYTHING ABOUT IT AT ALL, NOT EVEN A SINGLE KEYSTROKE! Then the very small frame has a very small page that refreshes itself every so often, possibly 80% of the session timeout. That lone little page is enough to keep the seesion from timing out.
BUT, there is a problem. If you do this, the session will NEVER timeout so long as the user has that page in the browser. If they go home for the night, the session stays running for the entire time the browser is open.
MWRivera wrote: The reason for this is that I want the session to expire if the user has no interaction for a period of time
That's what the session timeout is for.
MWRivera wrote: but if there is activity including text entered in the textbox then I want the session renewed.
Web applications cannot handle this situation. If the user is taking longer than the default 20 minutes to fill in a page and submit it, the correct course of action is to increase the session timeout, but only if you consider the side-effects of doing so.
|
|
|
|
|
Yes, that could be a problem with the session not expiring as we would then be relying on the user to logout or close the browser.
I didn't expect that there would be no way of refreshing the session when a user types in a textbox.
I guess this is something I will have to share with my team and go from there.
Thank you for your feedback.
Mel
|
|
|
|
|
I'm using the following code to run REGASM.EXE to register and create TLB files for some .NET assemblies. The output message indicates that the registration of each assembly was successful however since they are under an installation folder in C:\Program Files, the output message from REGASM doesn't show the full path of the assembly that was registered or exported as a tlb. It just shows 'C:\Program'. Is there any way to fix the output message so that it shows the full path?
private static bool ExecuteAndWait(string _FileToExecute, string _CommandLine, ref string _outputMessage, ref string _errorMessage)
{
Process p = null;
try
{
p= new Process();
p.StartInfo.FileName = _FileToExecute;
p.StartInfo.Arguments = _CommandLine;
p.StartInfo.RedirectStandardError = true;
p.StartInfo.RedirectStandardOutput = true;
p.StartInfo.UseShellExecute = false;
p.StartInfo.CreateNoWindow = false;
p.Start();
_errorMessage = p.StandardError.ReadToEnd();
p.WaitForExit();
_outputMessage = p.StandardOutput.ReadToEnd();
p.WaitForExit();
if (p.ExitCode != 0)
{
return false;
}
return true;
}
catch (Win32Exception _Win32Exception)
{
Console.WriteLine("Win32 Exception caught in process: {0}", _Win32Exception.ToString());
return false;
}
catch (Exception _Exception)
{
Console.WriteLine("Exception caught in process: {0}", _Exception.ToString());
return false;
}
finally
{
p.Close();
p.Dispose();
p = null;
}
}
|
|
|
|