Menu Items

Hi.
Anybody can explain how to enable or disable a menu item?

Thank you, very much

Santiago

Santiago,

> Anybody can explain how to enable or disable a menu item?

This question comes up quite often so if you download a copy of the
newsgroup archive from my web site (address below) then you should be able
to find a few fuller explanations.

Basically -

In Dolphin you enable the command a menu item uses and not the menu item
itself. This has the advantage that a single operation can disable a command
wherever it is originated - menu, toolbar, button.

The enabling/disabling is done in a method named #queryCommand: which is
often, but not always, placed in the main (shell) presenter of your
application. There are many examples of this method in the image.

When a menu is opened the #queryCommand: method is called once for each item
on the menu, with the command that the item sends embedded in the argument.
If you want to set the state for a specific item you can set the #isEnabled
(and #isChecked) attributes of the argument and this is then reflected in
the menu when it is drawn.

By default menu items are enabled if there is a method matching the command
available and disabled otherwise.

Regards
    Ian

http://www.iandb.org.uk

Thank you, Ian. I did it.


Ian Bartholomew wrote:

"Ian Bartholomew" <[hidden email]> wrote in
news:Cq0f8.1422$51.31058@wards:

> When a menu is opened the #queryCommand: method is called
> once for each item on the menu, with the command that the
> item sends embedded in the argument. If you want to set the
> state for a specific item you can set the #isEnabled (and
> #isChecked) attributes of the argument and this is then
> reflected in the menu when it is drawn.

Does anyone have any idioms which stop queryCommands being a mess of only barely
related clauses for the different commands, with lots of complex conditionals in each
clause? I've always thought this a bit of a wart in an otherwise quite elegant MVP, but
maybe that's just me :)

P.

Paul,

> > When a menu is opened the #queryCommand: method is called
> > once for each item on the menu, with the command that the
> > item sends embedded in the argument. If you want to set the
> > state for a specific item you can set the #isEnabled (and
> > #isChecked) attributes of the argument and this is then
> > reflected in the menu when it is drawn.
>
> Does anyone have any idioms which stop queryCommands being a mess of only
barely
> related clauses for the different commands, with lots of complex
conditionals in each
> clause? I've always thought this a bit of a wart in an otherwise quite
elegant MVP, but
> maybe that's just me :)

One approach would be to move the logic from the presenter into the command
objects themselves.  I'm thinking of what the GoF describes re undo etc..  I
did this in one app (not in its GUI though) that accepts "commands" from
various sources, and sequences and executes them.  It works very well, but,
it's not as spontaneous as coding a method and assigning its selector to a
button or menu item.  That particular app is (very) multi-threaded so the
extra effort was almost essential.

Have a good one,

Bill

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