On Jul 26, 2006, at 4:16 PM, Karen wrote:
On Jul 26, 2006, at 4:47 PM, Jonathan Johnson wrote:
1) Focused Control Menu Handler
2) Intrinsic focused-control menu handler (ie, built-in handler)
3) Window Menu Handler
4) "Parent" window menu handler (in the case of floating windows,
this would be the next non-floating window)
5) App Menu handler
6) MenuItem Action event
So, to override the default copy behavior of an EditField, create
an EditField subclass with an EditCopy menu handler.
Wait,that says if even if I have menu Handler but in my subclass
but want it handled at the window or app level for generality, it's
now impossible if an intrinsic handler exists? That seems VERY
wrong, if I have a handler and it returns false, it means I want to
handle it at higher level nota lower one.. and an intrinsic handler
SHOULD be the lowest one... Which means if I have defined a
handler, no matter if it handles it or not, the intrinsic handler
should not be called because it have been overridden
The problem with this is the situation I defined earlier: You have a
document window that defines EditCopy, and a floating window with an
EditField that you want to Just Work⢠(like they do in plain
situations). If you show the floating window and try to copy, the
parent window will attempt to handle that command. This caused
inconsistent behaviors which made EditCopy simply not work at all.
However, as with nearly any change in behaviors, there's good and bad
sides to it. We had a discussion internally, and concluded that the
new order seemed more correct. In this situation, there is a way to
make this function properly: create an EditField subclass and handle
your code there. The only situation I can think of that the default
EditCut/Copy/Paste/Clear behavior isn't desired is if the EditField
does a lot more than just regular styled text editing. In this case,
it would probably be cleaner and easier to maintain if all that logic
was wrapped in an EditField subclass rather than tied directly to the
window.
In other words if I define a handler in a subclass the intrinsic
handler should not be called as my intension is to override it...
Correct. And that's what it does. The Focused control menu handler is
what you would implement in a subclass. It's called before the
intrinsic one is called.
Intrinsic handler are of dubious value IMO... Not having them and
always providing functions that we can call from our own handlers
would be best I think
That would mean that for every Window you would have to add an
EditCopy, EditCut, EditPaste, EditClear menu handlers, and then ask
to see if the focused control is an EditField, if so, then call the
appropriate function. It cuts down on a lot of code, IMHO.
But, as always, if you want the behavior to change, please file a
feature request.
HTH,
Jon_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
