On 2010/12/04 21:03, commits at source.squeak.org wrote:
> David T. Lewis uploaded a new version of MorphicExtras to project The Trunk:
> http://source.squeak.org/trunk/MorphicExtras-fbs.95.mcz
>
> ==================== Summary ====================
>
> Name: MorphicExtras-fbs.95
> Author: fbs
> Time: 4 December 2010, 8:06:58.744 pm
> UUID: 29fdd44c-e506-b349-955c-c02d8c371e4b
> Ancestors: MorphicExtras-ul.94
>
> Attempting to open a telemorphic user when you have no network connection results in a dialog asking you to Retry a name lookup (as a network check) or Give Up. If you Give Up, your image will spew out a never-ending stream of debuggers. This change allows the user to see that she needs to make a network connection, but also allows her to abort the operation. See http://bugs.squeak.org/view.php?id=7578.
>
> =============== Diff against MorphicExtras-ul.94 ===============
>
> Item was changed:
>    ----- Method: RemoteHandMorph class>>ensureNetworkConnected (in category 'utilities') -----
>    ensureNetworkConnected
> + 	"Try to ensure that an intermittent network connection, such as a dialup or ISDN line, is actually connected. This is necessary to make sure a server is visible in order to accept an incoming connection. If the network connection does not work - the user has given up - return false. Otherwise, return true."
> - 	"Try to ensure that an intermittent network connection, such as a dialup or ISDN line, is actually connected. This is necessary to make sure a server is visible in order to accept an incoming connection."
>    	"RemoteHandMorph ensureNetworkConnected"
> + 	| address |
> -
>    	Utilities
> + 		informUser: 'Ensuring your network connection works...'
> - 		informUser: 'Contacting domain name server...'
>    		during: [
> + 			address := (NetNameResolver
> - 			NetNameResolver
>    				addressForName: 'squeak.org'
> + 				timeout: 30)].
> + 	^ address notNil.!
> - 				timeout: 30].
> - !

Yay!

Something that I found a bit tricky about this fix was figuring out how 
restarts work. An exception's signalled (NameLookupFailure, in this 
case) and because there's no enclosing #on:do: NLF's defaultAction 
invokes, which calls "self retry" which in turn calls "handlerContext 
restart" which unwinds the stack to the context that signalled the 
exception in the first place - the block argument to 
#informUser:during:, in other words.

So the above doesn't just look up a name to see if there's a network 
connection (obviously not a _foolproof_ method - it will fail in the 
presence of a local caching nameserver - but a decent, pragmatic 
choice), it also prompts the user to, say, plug in her network cable.

Would it be worth me writing a comment in this method to explain that 
"loop"? Something like "The below will repeatedly prompt you in the 
event of a failed lookup, to allow you to connect to a network, 
providing you with the option to give up." Because it wasn't at all 
obvious to me how/why a dialog popped up, and looped, when there's no 
look in the method. (The loop's in the control flow, thanks to the 
exception retrying.)

frank