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: >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 > > |
In reply to this post by Ian Bartholomew-7
"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] |
Free forum by Nabble | Edit this page |