[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Specializing WINDOW-MENU-I



To:     Matthew Cornell    cornell@unix1.cs.umass.edu
cc:     info-mcl
From:   Steve Mitchell
Date:   4/29/92
 
Sub:    Specializing WINDOW-MENU-ITEMs
 
> Hello. I'd like to use the Clear menu item for my own subclass of
> WINDOW. This subclass has different kinds of editable objects whose
> contents can be Cut, Cleared, etc. The docs say WINDOW-MENU-ITEMs
> (which is what the Clear menu item is an instance of) are updated
> based on whether the front window has a method for CLEAR. My subclass
> of window does have a method so the item is always enabled. The
> problem is this: I want to *selectively* enable the Clear menu item
> based on my window's current selection, much like FRED windows do
> based on if there's selected text. (I have more than just text that
> can be selected so I can't do exactly what FRED does.)
> I inspected the Clear menu item to find it is its update-function that
> does the refined updating. Disassebly shows this (anonymous) update
> function calls CCL::EDIT-MENU-ITEM-UPDATE which does the realy work,
> it seems.
> So I'm not sure how to do what I want. I don't want to replace the
> default Clear menu item because others depend on it. Similarly I don't
> want to change the item's update function. And I don't want to have a
> separate special set of editing menu items...
 
You said a couple weeks ago in a link you're using MCL 2.0f3:
 
(defmethod window-can-do-operation ((window my-window)
                                    operation &optional menu-item)
  "Return T if the window can do the operation, nil otherwise"
  (declare (ignore menu-item))
  (case operation
    (clear            (is-clearable-p *selected-object*))
    ((cut copy paste) ...)))
 
Of course you keep track of which object is selected, and you
write a method for is-clearable-p for each class. Any of
your editable object classes that inherit from fred-mixin
can have their own methods for window-can-do-operation and
be more object-oriented (they'll be identified via
current-key-handler).
 
_Steve