Hi
On Mon, Aug 22, 2005 at 12:10:45PM -0500, Robert P. Goldman wrote:
Similarly, as I mentioned earlier, it would be nice if one could use the ABORT gesture in the middle of ACCEPT and have something good happen. Seems like if I type something bad and can't fix it in input-editing, I'm just doomed to complete the interaction, and then have the command fail into the debugger. I looked into this a little, and it seemed like there was no place in the %ACCEPT code that looked for an ABORT gesture, but the bottom layers of McCLIM are pretty mysterious to me. Is this a GOATEE thing, or should it be handle by %ACCEPT or ACCEPT-FROM-STREAM? If you can give me a pointer, I'd be happy to try to fix it myself.
Some minutes after you seemed to have left the channel I posted a patch for you. Basically it is just adding (handler-bind ((abort-gesture #'abort)) in the beginning of ACCEPT in presentation-defs.lisp. That seems to be okay.
ABORT-GESTURE is the condition that is signaled when any of the gestures in *ABORT-GESTURES* is read (in STREAM-READ-GESTURE). Right now *ABORT-GESTURES* contains only :abort on mcclim, which is a the keyboard gesture (#\c :control) (on Genera it contains #\Abort, the ABORT-key).
I do not find explicitly in the clim specification that an accept should be aborted on any abort-gesture, but it seems to be the right thing.
I did short tests with ACCEPTING-VALUES and it seems to behave correctly with this patch, i.e. the whole dialog will be aborted. Or would it be better if only the editing of the single input-gadget is aborted?
Also Genera CLIM and Dynamic Windows behave in the same way, although one gets thrown into the debugger if one presses ABORT during editing a text-field of an CLIM:ACCEPTING-VALUES dialog... This does not happen with McCLIM and this patch.
If noone complains I'll apply it to the repository.
Regards, Max