 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Windows Forms / WinForm General / June 2004Window messages
Hi I just stumbled into a strange problem that I don't understand. My launcher application starts an executable after the load event. Actually I have the Load event handler set a timer for 200ms and the timer's Tick handler will do some work and then eventually start the application using Process.Start. In the execution of the Timer event I use a Process.WaitForExit function to halt the execution until the started application exits. This usually works fine, but not always. Our fault reporting system stopped working when people started using the launcher application and the reason for this seems to be that the timer's event handler will not finish until the launched application is closed. For some reason it seems to me that the Remedy system stopped to receive window messages when my launcher application was running the timer event. When that timer event was finished executing (the launched application was closed) the Remedy application would just continue to work as nothing had happened. Why is this not happening for all applications? My workaround was to use a separate thread that would launch the executable. I was still able to use the WaitForExit and when the tread was finished, the launcher would also exit. But the behaviour really puzzles me! Can anyone please shed some light on this? /Berndt Hi Berndt, Just as doc described, WaitForExit is used to make the current thread wait until the associated process terminates. It made the main thread blocked to wait for the process exit, the blocking of main thread also freezed the message loop, so that any communications to this application based on win32 message will be blocked. Are you using SendMessage in your fault reporting System and remedy system? Best regards, Ying-Shen Yu [MSFT] Microsoft Community Support Get Secure! - www.microsoft.com/security This posting is provided "AS IS" with no warranties and confers no rights. This mail should not be replied directly, please remove the word "online" before sending mail. Hi Sorry for not being up to speed on the messaging implementation in Win32. So, what you are saying is that freezing an eventhandler in a .net application will freeze the global message loop that other win32 applications use? Is this only happening on pure win32 application? The fault reporting system is not developed by ourselves, so I don't know how it has been implemented. /Berndt > Hi Berndt, > [quoted text clipped - 14 lines] > This mail should not be replied directly, please remove the word "online" > before sending mail. Hi Berndt, > So, what you are saying is that freezing an eventhandler in a .net > application will freeze the global message loop that other win32 > applications use? Is this only happening on pure win32 application? Ying-Shen didn't say such thing, I believe. First of all there is no such a thing as global message loop. There are message loops which are per thread. Even thought there is a system thread that dispatches keyboard and mouse messages from global message queue to threads' queues even if this thread block it will affect only the keyboard and the mouse but the applications will keep comunicating messages. So it doesn't happen neither on pure win32 application nor .NET. However if the launcher palys some role in the process of sending fault messages it might be the problem. The main UI thread of the launcher is blocked so it won't receive niether posted nor sent messages. -- HTH Stoitcho Goutsev (100) [C# MVP] > Hi > [quoted text clipped - 27 lines] > > This mail should not be replied directly, please remove the word "online" > > before sending mail. Thanks for clearing this up, Stoitcho. Berndt, my guess is these two application at least needs interacting with your launcher application, they need a reply from the launcher application to go on running, and they seems not have timeout options. It may be based on Win32 messages or some other IPC mechanisms, but I think this interaction needs the main thread of your launcher application, so if you blocked up the main thread, no reply will be sent. Creating a new thread to wait for process exiting should be fine. Best regards, Ying-Shen Yu [MSFT] Microsoft Community Support Get Secure! - www.microsoft.com/security This posting is provided "AS IS" with no warranties and confers no rights. This mail should not be replied directly, please remove the word "online" before sending mail. I am not sure that we understand each other now. The fault reporting system is a separate application that our testers use to report faults on our software and is usually running on the computer that the tester is using. This is not the application that the launcher is trying to launch, it just happens to be one application that hangs whenever the launcher is used. Which to me is odd, since Stoitcho said that the message queues are per thread. I mean, if the launchers only task is to launch an application (our own client application in this case) then when the application is launched I don't see why blocking the launcher's main thread (using WaitForExit) could do any harm. Actually that is what I want to do, since I need to perform some cleanup after the client application has terminated (remove extracted files etc.). Our own launched client app works just fine during the time when the launcher is blocked waiting for the client app exiting. But the fault reporting application just hangs until the launcher exits. When the launcher exits, the fault-reporting app just continues as if nothing had happened. The launcher application is coded to only work with our own client application (strong named assemblies and policies), so it shouldn't at all be concerned with the fault-reporting app. And if there is no such thing as a global message queue, then I certainly don't understand how our launcher application could cause any other application (the fault reporting application in this case) to stop responding.... Sorry if I was unclear about the setup in my previous postings. /Berndt > Thanks for clearing this up, Stoitcho. > [quoted text clipped - 15 lines] > This mail should not be replied directly, please remove the word "online" > before sending mail. Hi Berndt, Will the fault reporting system work if you move the clean up code into the Exited event handler and comment out the WaitForExit method? If it works, this issue I think is still related to the message loop of the launcher application. To do further investigation on this issue, I suggest you try attaching a debugger to the fault report system when it hangs, and check the call stack on its threads, probably we can see which call made the application hang. Note, to get the correct call stack information, you may need to load symbol files for both the fault report system and the windows system. Feel free to reply this thread if you have any problems on this issue. Best regards, Ying-Shen Yu [MSFT] Microsoft Community Support Get Secure! - www.microsoft.com/security This posting is provided "AS IS" with no warranties and confers no rights. This mail should not be replied directly, please remove the word "online" before sending mail. Well in this case it doesn't make any sense. Accept if the reporting application do something weird like enumearting all windows and trying to send some messages e.g. WM_GETTEXT in which case it will block.  SignatureStoitcho Goutsev (100) [C# MVP] > Hi Berndt, > [quoted text clipped - 20 lines] > This mail should not be replied directly, please remove the word "online" > before sending mail. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.