CollectionPresenter and toolbar enablement

I recently discovered CollectionPresenter and its subclasses (thanks to
the recent post about 20 bugs).  I've got several places where it fits
the bill pretty well.

In using it, I notice an odd behavior: the toolbar buttons are always
disabled unless the CollectionPresenter's view has focus.

My limited investigation suggests that it is related to the routing of
the queryCommand: methods.

I found that if the parent of the CollectionPresenter forwards
#queryCommand: on to the CollectionPresenter, then enablement works as
long as the parent presenter has focus.  But if it loses focus, then all
of the toolbar buttons are disabled again.  I have command buttons that
don't seem to suffer the same fate.  Is there something different about
toolbar buttons?

Is this a bug?  It seems like one to me; I'd like those buttons to stay
appropriately enabled at all times.  Is there a fix or workaround?

Thanks,
Randy
--
Randy Coulman
NOTE: Reply-to: address is spam-guarded.  Reassemble the following to
reply directly:
rcoulman at charter dot net

Randy,

> In using it, I notice an odd behavior: the toolbar buttons are always
> disabled unless the CollectionPresenter's view has focus.
> Is this a bug?  It seems like one to me; I'd like those buttons to stay
> appropriately enabled at all times.  Is there a fix or workaround?

As far as I unterstand it is a design decision.

When MVP needs to validate user interface it sends for every button or menu
command #queryCommand: to every view or presenter in an appropriate
commandPath. This commandPath starts with some view called commandSource and
goes up to the top shell view. You can view definitions of #commandSource to
see different implementations.

The Toolbar view implements it so, that the commandPath starts with the
currently focused view. It makes sence if some particular toolbar belongs
directly to a top shell and you want to enable or disable some buttons
according to the states of the top shells subpresenters. But it makes no
sence if you use a CollectionPresenter with its toolbar in some sub-view or
a dialog.
So we've subclassed the Toolbar view, overwrote the method commandSource:
commandSource

^self parentView! !

and appropriately changed the view resource in our sublass of the
CollectionPresenter. BTW the PushButton view has the same implementation of
the method.



Best Regards,

Maxim Fridental

Hello all,

> I found that if the parent of the CollectionPresenter forwards
> #queryCommand: on to the CollectionPresenter, then enablement works as
> long as the parent presenter has focus.  But if it loses focus, then all
> of the toolbar buttons are disabled again.  I have command buttons that
> don't seem to suffer the same fate.  Is there something different about
> toolbar buttons?
>
> Is this a bug?  It seems like one to me; I'd like those buttons to stay
> appropriately enabled at all times.  Is there a fix or workaround?

I _hope_ OA considers it a bug, because CollectionPresenter would be very
useful if it were better behaved in this respect.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Randy,

> Is this a bug?  It seems like one to me; I'd like those buttons to
> stay appropriately enabled at all times.  Is there a fix or
> workaround?

<warning> this code has had minimal testing

Perhaps you could add it to your main presenters command route -
something like

YourMainShell>>addToCommandRoute: route
    super addToCommandRoute: route.
    route appendPresenter: myCollectionPresenter

This leaves the button in the CollectionPresenter enabled and working
even when the CP is not the view in focus.  Is that what you wanted?

</warning>

--
Ian

Randy Coulman wrote:

> In using it, I notice an odd behavior: the toolbar buttons are always
> disabled unless the CollectionPresenter's view has focus.
>
> My limited investigation suggests that it is related to the routing of
> the queryCommand: methods.

I've had similar problems, and ended up with a subclass of Toolbar like Maxim
(I couldn't use Ian's solution because the top shell doesn't "know" about the
subviews with toolbars).

Although the framework did let me work around the problem, I don't think that
the way these things are put together is quite "right" -- I had to override
stuff with slightly modified copies of significant logic, which doesn't smell
right to me.

My subclass has a #commandPolicy that is similar in spirit to Maxim's (it's
more complicated because this is yet another of my pluggable architectures),
and that feels quite appropriate.  But I *also* had to copy+override
View>>commandPolicy to change the hardwired
     'self presenter commandSource'
to:
     'self commandSource'.

I had to do that because, in my app/architecture the toolbar View has a
Presenter set that isn't 'self'.  I could have defined a new kind of Presenter
with the specialised command policy logic, instead of using a default Presenter
and modifying #commandPolicy in my toolbar subclass.  Perhaps that's what I
"should" have done ?

Similarly, I had to copy+override the private Toolbar>>tbnDropDown: because it
sends #onDropDown: to its Presenter, but there's no standard Presenter that
understands that message.  Which, I suppose, is further evidence that I'd have
been better off creating a new kind of Presenter, although I think it must be a
bug that I have to do it.

    -- chris