CLIM mail archive
[Prev][Next][Index][Thread]
Re: command-enabled
>From: Daniel Cerys <cerys@BBN.COM>
>Subject: Re: command-enabled
>Date: Mon, 18 Apr 94 08:43:36 EDT
>
>Chris Elsaesser wrote on 18 April 1994:
> > Clim-2-beta ... Lucid 4.0.3
> > When I do:
> > (setf (clim:command-enabled 'com-Run *frame* *control-commands*) nil)
> > [bug deleted]
>This must be a partially implemented Lucid extension. I'm using Franz'
>CLIM and I get:
>COMMAND-ENABLED's arglist: (COMMAND-NAME (FRAME
STANDARD-APPLICATION-FRAME))
>just as the documentation claims. To be honest, I don't know what the
>command-table argument would even do; it's unnecessary given the frame.
>
>Dan
Just as a footnote: It's worth mentioning the the other approach here which
is to specialize the COMMAND-ENABLED method on the command-name (and the
frame, of course).
This more "functional" approach is sometimes quite useful (for example when
used on the commands on a pull-down menu-bar). In particular it saves me
the grief of keeping track of the bookkeeping involved in enabling and
disabling the various commands.
I totally agree. However, from a recent discussion (somewhere in January)
on this topic
I was told that implementations using a window toolkit (e.g., motif)
usually dont update
the enabled-status of pull-down menus unless you use the non-functional
approach.
The reason was that it would be too inefficient if every pull-down menu
would have to
check command-enabled-p before displaying its menu-items.
Also the SETF-like approach seems to cause the DISABLED-COMMANDS slot on
the frame to grow without bounds (at least this is true on the FRANZ that
I'm using). This makes things like DESCRIBE-ing the frame somewhat
painful. More an annoyance than a bug really, but still...
N
;;; - Stefan Bernemann (berni@iml.fhg.de)
Main Index |
Thread Index