queryCommand defines a return value which however is never used. It looks
like it was for aborting the search when returning false but the code for this is missing in queryAlong or similiar location. Is this just legacy or a bug? Regards Carsten Haerle |
"Carsten Haerle" <[hidden email]> wrote in message
news:41121086$0$26990$[hidden email]... > queryCommand defines a return value which however is never used. It looks > like it was for aborting the search when returning false but the code for > this is missing in queryAlong or similiar location. Is this just legacy or > a > bug? The return value is intended as an indication as to whether the command target recognised the command, not to control the command routing operation. A command querying method should return false if it didn't recognise the command, and true if it did, in either case the command routing could (and should) continue to other command targets in the chain if a command target prepared to accept the command has not yet been found. The command routing code (see CommandPolicy>>queryCommand:) stops routing a command only when it detects that a command receiver has been set. It sets the receiver itself when a command target enables the command. To stop command routing without enabling the command, disable the command, and set the receiver to something other than nil (most conveniently the command target doing the disabling). The return value can be useful in your own code, since it helps in the implementation of a useful pattern for breaking down #queryCommand: into pieces. I frequently use code of this general form: queryCommand: aCommandQuery ^(self queryWibbleCommand: aCommandQuery) or: [self queryWobbleCommand: aCommandQuery or: [super queryCommand: aCommandQuery]] While we are on the subject of useful command querying idioms, another useful one is for handling context sensitive commands that map to a number of different commands. Lets say I have a #wibbleIt command, that might do a #wibble or a #wobble depending on selection. A useful way to implement that is as follows: queryCommand: aCommandQuery | selector | selector := aCommandQuery commandSymbol. selector == #wibbleIt ifTrue: [ selector := self wibbleItCommand. selector isNil ifTrue: [aCommandQuery isEnabled: false. ^true]]. selector == #wobble ifTrue: [...etc.... ^true]. selector == #wibble ifTrue: [...etc.... ^true]. ^false The #wibbleIt command itself is implemented as follows: wibbleIt self perform: self wibbleItCommand To apply the two idioms together, add a parameter to the subsidiary command querying methods, and pass the selector. Examples of both idioms can be found in the development system tools. Lastly if the standard CommandPolicy (actually DelegatingCommandPolicy) does not meet your needs (it should since it is very flexible in that it involves the presenter chain in the building of the command route, which provides it a great deal of flexibility), then you can supply your own. Subclass CommandPolicy, override as necessary, and then add a #commandPolicyClass method to your Shell presenter subclass(es). Regards Blair |
Free forum by Nabble | Edit this page |