Basically, the touch event on screen fires an event, which calls the code to send the TCP-IP message on a separate thread. There's error trapping in every function to hide the UIAlertView regardless of what happens - but it seems the TcpClient send method doesn't return until the phone is dropped - this is the only way the UIAlertView can't be hidden. If it returned, the UIAlertView would have been hidden.
But it's not consistent - it works perfectly 99% of the time, the other 1% of the time a drop makes it work. And yeah. I'm trying to explain this to my CEO. Not going well. Dino From: Miguel de Icaza [mailto:[email protected]] Sent: Thursday, October 27, 2011 8:54 PM To: Dean Cleaver Cc: Forums, MonoTouch ([email protected]) Subject: Re: [MonoTouch] Too weird for words I didn't believe it, but I have seen a video of it as proof... I have some code that sends a TCP-IP message. It pops a UIAlertView with no buttons and an activity indicator to show that something is happening. 99% of the time, it's gone in 1 to 5 seconds, but sometimes it takes longer - a lot longer. What's on the video is apparently reproducible, although to produce a sample will be night on impossible - but if it takes ages (like 1 or more minutes) they just drop the phone onto the desk (from about 6" to 12" high) and magically it hides the indicator and the app carries on perfectly. Every time they do it regardless of waiting 30 seconds or 3 minutes, it *ALWAYS* works the instant they drop it. Likely the accelerometer detects the motion and posts a message to your run loop that says "Device is being shaken" (you have seen this in text fields, when you shake you get a "Undo Typing" button). Probably the message posted to the main loop is unblocking whatever pending operation is queued, even if nothing happens on the screen. Hard to diagnose without looking at the code. Miguel
_______________________________________________ MonoTouch mailing list [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
