deactivating sub-menu items

• To: SWM@stony-brook.scrc.symbolics.com, clim@BBN.COM
• Subject: deactivating sub-menu items
• From: Anton Beschta <beschta@arms4.zfe.siemens.de>
• Date: Fri, 29 Oct 93 09:20:27 +0100
• In-Reply-To: Scott McKay's message of Thu, 28 Oct 1993 13:53 -0400 <19931028175337.7.SWM@SUMMER.SCRC.Symbolics.COM>
• Reply-To: beschta@zfe.siemens.de

   Date: Thu, 28 Oct 1993 13:53 -0400
   From: Scott McKay <SWM@stony-brook.scrc.symbolics.com>

   When I realized this hole was there, I came up with a kludge.  On the
   assumption that command names and command *table* names are disjoint,
   we could always allow (SETF (COMMAND-ENABLED <comtab-name>) NIL), and
   simply fix the one or two places in CLIM that call COMMAND-ENABLED to
   also check for the case of a command table being enabled/disabled.

   Is this kludge just too awful?  Should we come up with something real
   for this, or do people think it's OK to overload COMMAND-ENABLED to
   support enabling/disabling of command tables as well as commands?

I don't think that's a good idea. The function name COMMAND-ENABLED
simply suggests something different. And I always prefer function
names that "talk" to me. From my point of view providing a
COMMAND-TABLE-ENABLED function and an associated setf-method
is much more natural.

-Tony

• deactivating sub-menu items
• From: Scott McKay <SWM@stony-brook.scrc.symbolics.com>

• Prev: MCL CLIM 1.1 bug: define-presentation-type compiler error
• Next: Re: deactivating sub-menu items
• Index: CLIM Mailing list (1-Jan-93 to 31-May-94)
• Thread: CLIM Mailing list Index (1-Jan-93 to 31-May-94)