queryCommand: and menus

Hi,
I'm having a problem enabling menus for a Shell I'm working with, and
wonder if I can get some help. Currently, I'm using queryCommand to
enable the command (used for both Pushbuttons and the menu items) --
the pushbuttons enable fine, but I'm not getting any response from the
menu bar -- totally disabled. I know I'm doing something stupid here,
but just can't seem to figure it out...
Here's a snippet:
queryCommand: aCommandQuery
   super queryCommand: aCommandQuery.
   (( aCommandQuery command == #runTest ) and: [ numberOfQuestions > 0
])
        ifTrue: [ aCommandQuery isEnabled: true. aCommandQuery receiver: self
].

   (( aCommandQuery command == #runTest ) and: [ numberOfQuestions <=
0 ])
        ifTrue: [ aCommandQuery isEnabled: false. aCommandQuery receiver:
self ].

<...etc...>
Anyway, my Shell implements the #runTest method, so I *thought*
(wrongly, I guess) that I'd be fine. Again, the buttons work okay, and
send the correct message as I'm implementing the same command with
them.

Any hints appreciated....

Thanks,

KeithB

ksbag <[hidden email]> wrote in message
news:[hidden email]...
> Hi,
> I'm having a problem enabling menus for a Shell I'm working with, and
> wonder if I can get some help. Currently, I'm using queryCommand to
> enable the command (used for both Pushbuttons and the menu items) --
> the pushbuttons enable fine, but I'm not getting any response from the
> menu bar -- totally disabled. I know I'm doing something stupid here,
> but just can't seem to figure it out...
...

I think one problem is that you are not returning true (^true) after you
handle the query.  Since the system does not know that the query has been
handled it does not refresh.  Take a look at some system implementations of
#queryCommand: for an example.

Chris

[hidden email] (ksbag) wrote in message news:<[hidden email]>...
> Hi,
> I'm having a problem enabling menus for a Shell I'm working with, and
> wonder if I can get some help. Currently, I'm using queryCommand to
<snip...>

Okay...I kept playing around, and finally got things working by
removing the name aspect for each of my menus. I guess I'm still kind
of fuzzy on what I was doing wrong:
- I used the RC to give a symbolic name to each of my menus (and the
menubar itself). After looking at the Calculator example, I noticed OA
didn't use any names for any these components at all -- they used nil
for the menubar and menus. So, I tried that. I reset the menu names to
nil, and now everything works as expected. Only problem is, I don't
understand *why*. Is there some rule about not naming your components
in the RC? I'm glad things are working, but I'm bothered by the fact
that I don't understand the subtleties of what's going on here...and I
haven't seen a lot of documentation explaining this.
Again, any tips, hints, clues, documentation appreciated....

Thanks,

KeithB

ksbag wrote:

> Okay...I kept playing around, and finally got things working by
> removing the name aspect for each of my menus

The name aspect of the menu is (only?) used for dynamically generated menus
(look for implementations of #onAboutToDisplayMenu:).  If you are using
dynamic menus then the #queryCommand: mechanism is used to validate the menu
itself too.  So if your menu is called #myDynamicMenu then you'll have to
trap the case where the command is #myDynamicMenu in your #queryCommand: and
set the query to be enabled, or else the menu won't be.

If you are using static menus, generated from the View Composer, say, then
this is irrelevant to you, so you don't name the menus, and then you don't
have to bother with handling them in #queryCommand:.

    -- chris

Christopher J. Demers wrote:

> I think one problem is that you are not returning true (^true) after you
> handle the query.  Since the system does not know that the query has been
> handled it does not refresh.  Take a look at some system implementations
of
> #queryCommand: for an example.

I'm fairly sure that that is not necessary.  Although many/most of the
system examples do take care to propagate the return value of #queryCommand,
I think the value is discarded when it gets to the top of the chain (see
CommandPolicy>>queryCommand:).

Certainly I've never answered anything but self from #queryCommand: and have
never had any problems with that aspect of it.

    -- chris

Chris Uppal <[hidden email]> wrote in message
news:[hidden email]...
> Christopher J. Demers wrote:
>
> > I think one problem is that you are not returning true (^true) after you
> > handle the query.  Since the system does not know that the query has
been
> > handled it does not refresh.  Take a look at some system implementations
> of
> > #queryCommand: for an example.
>
> I'm fairly sure that that is not necessary.  Although many/most of the
> system examples do take care to propagate the return value of
#queryCommand,
> I think the value is discarded when it gets to the top of the chain (see
> CommandPolicy>>queryCommand:).
...

I assumed it was important so I always did it.  I guess it is just window
dressing after all. ;)

Chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> ksbag wrote:
>
> > Okay...I kept playing around, and finally got things working by
> > removing the name aspect for each of my menus
>
> The name aspect of the menu is (only?) used for dynamically generated
menus
> (look for implementations of #onAboutToDisplayMenu:).  If you are using
> dynamic menus then the #queryCommand: mechanism is used to validate the
menu
> itself too.  So if your menu is called #myDynamicMenu then you'll have to
> trap the case where the command is #myDynamicMenu in your #queryCommand:
and
> set the query to be enabled, or else the menu won't be.
>
> If you are using static menus, generated from the View Composer, say, then
> this is irrelevant to you, so you don't name the menus, and then you don't
> have to bother with handling them in #queryCommand:.

That is correct. The only cases where you would want to name a menu are:
a) You wan't to be able to enable/disable the entire menu (it being
preferable from a usability point of view to disable an entire menu rather
than every individual item on it)
b) You want to implement menus with dynamically variable content.

Regards

Blair

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> Christopher J. Demers wrote:
>
> > I think one problem is that you are not returning true (^true) after you
> > handle the query.  Since the system does not know that the query has
been
> > handled it does not refresh.  Take a look at some system implementations
> of
> > #queryCommand: for an example.
>
> I'm fairly sure that that is not necessary.  Although many/most of the
> system examples do take care to propagate the return value of
#queryCommand,
> I think the value is discarded when it gets to the top of the chain (see
> CommandPolicy>>queryCommand:).
>
> Certainly I've never answered anything but self from #queryCommand: and
have
> never had any problems with that aspect of it.

I recommend returning true/false from #queryCommand: (indicating whether or
not the command has found a target) as it is useful if the method gets large
and you want to refactor it down into a number of methods connected with
#or:, for example:

queryCommand: aCommandQuery

 ^(self queryDebugCommand: aCommandQuery) or:
   [(self queryInspectCommand: aCommandQuery)
    or: [(self queryMiscCommand: aCommandQuery) or: [super queryCommand:
aCommandQuery]]]

Regards

Blair