A #queryCommand: issue? (Dolphin 5)

Hi there,

 I'm experiencing a strange behavior with a couple of presenters here.
I've made two presenters that are not much than a list with a toolbar
in the north. The toolbars in this presenters has the usual #addItem
....#removeItem commands.

 I make use of #queryCommand: to enable/disable the #addItem, etc
commands depending on the list selection state. For instance I disable
the #moveDown and #moveLast commands if the selection are in the lowest
place. I also enable the #addItem of the second list, only when the
first list has an element selected. The #addItem of the first list is
always enabled.

 I have this presenters joined together as references in another
*joiner* presenter. Thats because I want several elements in the second
list for each one in the first list.

 When I open them in a dialog (wich refers this joiner presenter) I
found that the toolbar commands are enabling/disabling all the same
depending in the state of the first list (and not the list each one is
attached to, and that alone). The #addItem of the second list never
disables. More that that, if I open the dialog and touch the #addItem
button of the second list, then, the #addItem of the first presenter is
executed.

 Then, and only if I first make a click on the white space of the
second list (make it gain focus) the toolbar of this list starts to
behave as it is espected to behave in first place.

 So...

1) could this be a limitation on the #queryCommand: subsystem?
2) do #queryCommand: support the *same name* commands in different
referencial presenters to be properly consulted?
3) If not, anybody have a workarround for this?

  thank you,

Sebastián

Not sure if I followed the problem, but could it be that in this case the
command must be explicitly routed using #addToCommandRoute:, or creating
your own CommandPolicy ?

regards
martin

"Sebastián" <[hidden email]> escribió en el mensaje
news:[hidden email]...
Hi there,

 I'm experiencing a strange behavior with a couple of presenters here.
I've made two presenters that are not much than a list with a toolbar
in the north. The toolbars in this presenters has the usual #addItem
....#removeItem commands.

 I make use of #queryCommand: to enable/disable the #addItem, etc
commands depending on the list selection state. For instance I disable
the #moveDown and #moveLast commands if the selection are in the lowest
place. I also enable the #addItem of the second list, only when the
first list has an element selected. The #addItem of the first list is
always enabled.

 I have this presenters joined together as references in another
*joiner* presenter. Thats because I want several elements in the second
list for each one in the first list.

 When I open them in a dialog (wich refers this joiner presenter) I
found that the toolbar commands are enabling/disabling all the same
depending in the state of the first list (and not the list each one is
attached to, and that alone). The #addItem of the second list never
disables. More that that, if I open the dialog and touch the #addItem
button of the second list, then, the #addItem of the first presenter is
executed.

 Then, and only if I first make a click on the white space of the
second list (make it gain focus) the toolbar of this list starts to
behave as it is espected to behave in first place.

 So...

1) could this be a limitation on the #queryCommand: subsystem?
2) do #queryCommand: support the *same name* commands in different
referencial presenters to be properly consulted?
3) If not, anybody have a workarround for this?

  thank you,

Sebastián

Sebastián,

> 1) could this be a limitation on the #queryCommand: subsystem?

I wouldn't call it a limitation but, yes, it is a feature. The command
routing tries to help you by routing commands up the presenter parent
hierarchy chain. Obviously if you have two commands with the same name
but different actions, this is not going to work.

> 2) do #queryCommand: support the *same name* commands in different
> referencial presenters to be properly consulted?

No (as stated above).

> 3) If not, anybody have a workarround for this?

What you need to do is to create new commands that are actioned by the
top-level "joiner" presenter. Call them #addToListA and #addToListB
etc:. Implement these in the joiner presenter to forward the commands
on to the appropriate list, e.g.:

Joiner>>addToListA
        listA addItem

Joiner>>addToListB
        listB addItem

The point is that if you have a situation where you have several
widgets with the same named context commands then you can only expect
these to work as context commands (i.e. by a right click on the widget
to which the command should be directed). So you shouldn't implement
context commands at a higher level (it doesn't make sense because they
are then no longer strictly context commands).

What you need is some form of redirection. Yes, we could have
complicated the command routing further by adding a UI to set up
appropriate redirection but it seems cleaner and clearer to require
additional code instead (as above).

Best regards,

--
Andy Bower
Dolphin Support
www.object-arts.com

Dear Andy,

 I understood your point but that clearer and cleaner approach is
unpractical and antieconomical to my design because I have near 10
presenters wich can #addItem #removeItem #moveFirst #moveDown #moveUp
#moveLast. So I want to ask if you have another approach that respect
the original command names and still solve the inconvinience.
I should take a deeper look into the CommandPolicy as Martin says? Do
you think is solvable if I take that way? suggestions? other options?

thank you,

Sebastián