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