--- a/QuerySignal.st	Sat Sep 06 19:17:45 1997 +0200
+++ b/QuerySignal.st	Sat Sep 06 19:22:50 1997 +0200
@@ -13,7 +13,7 @@
 'From Smalltalk/X, Version:3.1.9 on 31-aug-1997 at 8:06:37 pm'                  !
 
 Signal subclass:#QuerySignal
-	instanceVariableNames:''
+	instanceVariableNames:'defaultAnswer hasDefault'
 	classVariableNames:''
 	poolDictionaries:''
 	category:'Kernel-Exceptions'
@@ -41,7 +41,8 @@
     by handlers for ordinary signals.
     I.e. a signal handler for a normal signal will not handle a query
     signal. Thus, these bypass anySignal handlers.
-    If unhandled, no error is raised, instead they are simply ignored
+
+    However, if unhandled, no error is raised, instead they are simply ignored
     and nil is returned from the raise
     (as opposed to normal signals, which raise an unhandled signal exception).
     QuerySignals are also ignored, if a handler exists, but rejects.
@@ -52,7 +53,7 @@
      would catch those signals).
 
     Code deep down in the calling hierarchy can post such an up-Query to ask
-    for some information in return or to pass some information upward. 
+    for some information or to pass some information upward. 
 
     For example, the activityNotification mechanism is built on top of this:
     everyone can send such a notification which is either handled by someone
@@ -70,18 +71,22 @@
     A highly elegant solution to this problem is to provide a handler somewhere
     at the top of the calling hierarchy, and raise an upQuery from whereever
     that value is required.
-    A concrete application can be found in the windowGroup- and lastEvent-
-    queries, provided by the windowGroup object. If anyone is interested
-    in the event which was responible for the anyone to be called, all he needs
-    to do is to raise the lastEventQuerySignal, which returns that event.
+    A concrete application can be found in the windowGroup-lastEvent
+    queries. If anyone is interested in the windowEvent which was responible for 
+    being invoked, all he needs to do is to raise the lastEventQuerySignal, 
+    which returns that event.
     No intermediate methods are required to know anything about that.
+    Another example is found in the way Metaclass asks for the nameSpace
+    when new classes are to be installed. A Browser may simply answer such
+    a query and provide a namespace (no need to pass that information down
+    the calling chain).
 
     A final note (to C++ and Java fans):
         such upQueries are only possible, if the exception handling mechanism
         does not automatically unwind the stack for the handler invokation.
         Since the handler must be able to proceed the execution and return
         a value to the raiser ....
-
+	... another demonstration of why ST's exception mechanisms are superior.
 
     [see also:]
         Signal SignalSet Exception
@@ -277,6 +282,9 @@
 
     |handler|
 
+    defaultAnswer := someValue.
+    hasDefault := true.
+
     "/ avoid creating a fullBlock, in the most common cases
     someValue == true ifTrue:[
         handler := [:ex | ex proceedWith:true]
@@ -284,7 +292,11 @@
         someValue == false ifTrue:[
             handler := [:ex | ex proceedWith:false]
         ] ifFalse:[
-            handler := [:ex | ex proceedWith:someValue].
+            someValue isNil ifTrue:[
+                handler := [:ex | ex proceedWith:nil]
+            ] ifFalse:[
+                handler := [:ex | ex proceedWith:someValue].
+	    ]
         ]
     ].
     self handlerBlock:handler.
@@ -377,6 +389,9 @@
         ]
     ].
     "/ no handler found - return the default value
+    hasDefault == true ifTrue:[
+	^ defaultAnswer
+    ].
     handlerBlock isNil ifTrue:[
         ^ nil
     ].
@@ -388,5 +403,5 @@
 !QuerySignal class methodsFor:'documentation'!
 
 version
-    ^ '$Header: /cvs/stx/stx/libbasic/QuerySignal.st,v 1.20 1997-09-02 17:40:17 cg Exp $'
+    ^ '$Header: /cvs/stx/stx/libbasic/QuerySignal.st,v 1.21 1997-09-06 17:22:50 cg Exp $'
 ! !