New topic: Knowing when the App is Quitting
<http://forums.realsoftware.com/viewtopic.php?t=30575> Page 1 of 1 [ 11 posts ] Previous topic | Next topic Author Message Phil M Post subject: Knowing when the App is QuittingPosted: Tue Oct 20, 2009 7:05 pm Joined: Fri Sep 30, 2005 12:18 pm Posts: 172 I have always added a property to the App class "IsQuitting As Boolean = False" and set the value to True in the App.Close event. This variable is important for various things (such as to hide a window or actually close it), but it is most important for me right now dealing with Sockets. In order to allow the sockets to "run in the background" I have the Yield property set to True, and control timeouts using a specialized Timer class. My problem with Socket.Yield is that the application will hang on closing until either that socket has completed its transaction or the timeout expires... unless I also check for some kind of App.IsQuitting variable within the timer object. But now I am packaging this code up to release as open source resource and obviously I cannot have someone drop in my class and expect it to work. So my question is... do I enforce an App.IsQuitting variable or is there another way to test if the application is quitting without adding any code to the New Project app object? Top mrebar Post subject: Re: Knowing when the App is QuittingPosted: Tue Oct 20, 2009 7:24 pm Joined: Wed Feb 15, 2006 1:30 pm Posts: 2926 Location: U.S.A (often), Creswell, often Dallas, Atlanta, Spokane, Pago Pago. I'm not certain that there's a great general case approach given what you've described. I'd be tempted to use the CancelClose event in the associated window or app and use a variable similar to your isQuitting to determine whether the sockets are done or stalled and can therefore be nuked. Michael _________________ RB 2009r2, OS 10.5.6, Win XP SP 3 Top Phil M Post subject: Re: Knowing when the App is QuittingPosted: Tue Oct 20, 2009 7:30 pm Joined: Fri Sep 30, 2005 12:18 pm Posts: 172 For this particular socket implementation, a window isn't even used... in fact this socket can be used in a Console app with no problems. Top guykuo Post subject: Re: Knowing when the App is QuittingPosted: Tue Oct 20, 2009 8:21 pm Joined: Mon Apr 02, 2007 5:51 pm Posts: 176 The only thing that comes to mind that will always fire at application end, would be your class's destructor, but does the socket.yield mean the app won't quit until your socket releases? Top Phil M Post subject: Re: Knowing when the App is QuittingPosted: Tue Oct 20, 2009 9:28 pm Joined: Fri Sep 30, 2005 12:18 pm Posts: 172 guykuo wrote:but does the socket.yield mean the app won't quit until your socket releases? Yes exactly... and the case would be even worse if I DIDN'T have a timer to give it a timeout period. Thats how I discovered the issue actually... putting in an unavailable URL without the timer caused the app to hang (App.Close event completed). Btw, the purpose I am doing this for is a HTTPSocket.Post to my website to determine if there newer versions of the software available. There is a user-activated check in the Preference window, but mostly this class is used passively in the background (after so many days since last check) therefore the need to use Yield. Top pony Post subject: Re: Knowing when the App is QuittingPosted: Tue Oct 20, 2009 9:50 pm Joined: Sat Nov 11, 2006 2:43 pm Posts: 365 Location: DFW area, Texas, USA Phil M wrote:guykuo wrote:but does the socket.yield mean the app won't quit until your socket releases? Yes exactly... and the case would be even worse if I DIDN'T have a timer to give it a timeout period. Thats how I discovered the issue actually... putting in an unavailable URL without the timer caused the app to hang (App.Close event completed). Btw, the purpose I am doing this for is a HTTPSocket.Post to my website to determine if there newer versions of the software available. There is a user-activated check in the Preference window, but mostly this class is used passively in the background (after so many days since last check) therefore the need to use Yield. It sounds like a DNS timeout hang. I just did a simple test Code:Dim socket1 as New HTTPSocket Dim f as FolderItem f =SpecialFolder.Desktop.Child("test") socket1.get "http://mywebsite.com/my10gigtestfile.dat",f The file was extremely large and would take several minutes to download. Closing the application stopped the download without any stall. I tried the above code in the action event of a push button, and also in a code thread - both worked just fine. One of my applications is TCP based and relies heavily on a network connection. DNS resolution failures cause RB to stall - I work around this by spawning a couple of shells and looking up the hosts - if they pass I proceed, if they fail I don't use the RB class. _________________ Fly like a mouse, run like a cushion, be the small bookcase. Beware the Aguamoose Man. Last edited by pony on Tue Oct 20, 2009 10:05 pm, edited 1 time in total. Top Phil M Post subject: Re: Knowing when the App is QuittingPosted: Tue Oct 20, 2009 10:04 pm Joined: Fri Sep 30, 2005 12:18 pm Posts: 172 Very good point, but one thing I noticed about your code is that you didn't use the HTTPSocket.Yield ... does that make a difference for you? Also, I don't believe its just DNS lookup errors, but also for unresponsive servers that I have this issue. Top pony Post subject: Re: Knowing when the App is QuittingPosted: Tue Oct 20, 2009 10:08 pm Joined: Sat Nov 11, 2006 2:43 pm Posts: 365 Location: DFW area, Texas, USA Setting yield to true made no difference in either the pushbutton.action event or the thread. _________________ Fly like a mouse, run like a cushion, be the small bookcase. Beware the Aguamoose Man. Top pony Post subject: Re: Knowing when the App is QuittingPosted: Tue Oct 20, 2009 10:22 pm Joined: Sat Nov 11, 2006 2:43 pm Posts: 365 Location: DFW area, Texas, USA Phil M wrote:Also, I don't believe its just DNS lookup errors, but also for unresponsive servers that I have this issue. I'm not sure how RB implements the class. Due to the nature of TCP/IP and the fact that packets may not necessarily arrive in the correct order, I'd be surprised if latency caused the application to stall when it quit - I may be wrong. My ISP is a rural community WiFi provider. The system is extremely basic, with antennas stuck on water towers and interconnected with home grade 8 port hubs at each site! Right now my maximum TCP delay is running at 209ms, 53% upload QoS, 67% download QoS, average download pause 17ms My service is prone to delays, outages, etc. The only problem I experienced was DNS resolution causing stalls. Maybe others can expand on my observations. _________________ Fly like a mouse, run like a cushion, be the small bookcase. Beware the Aguamoose Man. Top Phil M Post subject: Re: Knowing when the App is QuittingPosted: Tue Oct 20, 2009 10:33 pm Joined: Fri Sep 30, 2005 12:18 pm Posts: 172 What I mean by unresponsive server... it might be one that is overloaded (too many requests) or offline because of power failures etc. The DNS for that server is valid but, the HTTPSocket cannot establish a connection. And the timeout period I am using is 15 seconds... so my HTTPSocket will continue looking for the server for the full 15 seconds and a Quit command during the poll will hang until timeout expires. Top guykuo Post subject: Re: Knowing when the App is QuittingPosted: Tue Oct 20, 2009 11:53 pm Joined: Mon Apr 02, 2007 5:51 pm Posts: 176 I do roughly the same for my version checking. First I do a shell command to see if I can ping a likely to be up website to test that there is a live network connection. Then I do a httpsocket.get with yield true and a timeout of 5 seconds. That will get the test response 95% of the time within five seconds. The timeout is short enough that even if there is a hang, the user never realizes something is awry. Of course, sometimes we miss the update check, but that's not a huge issue. The test runs automatically in the background at app startup. It can also be triggered manually by the user. A potential 15 second hang would be completely unacceptable when launching or quitting my EMR app. I think you just have to be able to work around updates not always being detected every single time. BTW, I get the check to happen in the background by having it happen in the event handler of a single shot timer that fires after the ping test succeeds. Top Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost timeSubject AscendingDescending Page 1 of 1 [ 11 posts ] -- Over 1500 classes with 29000 functions in one REALbasic plug-in collection. The Monkeybread Software Realbasic Plugin v9.3. http://www.monkeybreadsoftware.de/realbasic/plugins.shtml [email protected]
