[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Specializing WINDOW-MENU-I
- To: CORNELL@UNIX1.CS.UMASS.EDU
- Subject: Re: Specializing WINDOW-MENU-I
- From: STEVE.M@AppleLink.Apple.COM (Carbon-based, S Mitchell,APD)
- Date: 30 Apr 92 07:17 GMT
- Cc: INFO-MCL@CAMBRIDGE.APPLE.COM
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