Bug in command routing from PushButtons

Following on from Yar Hwee Boon's thread: "#queryCommand: not called if a
button's command changes", we've  persuaded ourselves (or I have, anyway) that
there's a bug in routing commands from buttons.  I though I'd break the
description out from that rather complex thread.

This is the basic situation:  a Shell contains a sub-presenter and a
PushButton.  The sub-presenter understands some command, #doSomething, and has
the corresponding code in its #queryCommand:.  The PushButton's command is
#doSomething.  The Shell itself knows nothing about that command.

In this situation, the button will be enabled (provided that the
sub-presenter's #queryCommand: allows it) if the focus lies in the
sub-presenter.  (Or the 'lastFocus' was with the sub-presenter.)   I presume
that this is the intended behaviour -- the enabledness is controlled by a
command route starting at the current focus -- similar to a toolbar button.

However, if I then attempt to press the button, the focus changes to the
button, so the default command routing no longer includes the sub-presenter.
That means that the button will "suddenly" become disabled, and the
#doSomething command will not be invoked -- even though the button /was/
enabled when I decided to press it.

I believe that to be a bug -- though I admit I don't know how to fix it.

Yar Hwee Boon's problem is actually a bit more complicated in that he has the
equivalent of #doSomething understood by both the Shell and the sub-presenter,
but I think the above is the essence of the problem.

    -- chris

On Tue, 20 Jul 2004 12:14:04 +0100, Chris Uppal  
<[hidden email]> wrote:

> Following on from Yar Hwee Boon's thread: "#queryCommand: not called if a
> button's command changes", we've  persuaded ourselves (or I have,  
> anyway) that
> there's a bug in routing commands from buttons.  I though I'd break the
> description out from that rather complex thread.

I'm persuaded too :) Thanks for the excellent summary.

> presume
> that this is the intended behaviour -- the enabledness is controlled by a
> command route starting at the current focus -- similar to a toolbar  
> button.

As a sidenote, I must admit that I had found this quite unintuitive,  
although it really helps for toolbars. But has anyone utilized this  
behavior for push buttons?

> Yar Hwee Boon's problem is actually a bit more complicated in that he  
> has the
> equivalent of #doSomething understood by both the Shell and the  
> sub-presenter,
> but I think the above is the essence of the problem.

Once I understood and accepted that buttons are routed starting from the  
last focus, renaming one of the #doSomething (in subpresenter or shell)  
causes this problem to go away (but this just don't feel "right", why  
can't I give them the same name :)). Nevertheless, I'm still interested if  
anyone has a way around the problem above.

--
Regards
Hwee Boon
MotionObj

Hi,
I have subclass Toolbar and override #commandSource method with:
commandSource
   ^self parentView

this is the behavior I was expecting and maybe is what you were expecting
too.

Diego