Menu

#258 alt-F4 doesn't quit in windows

2: Annoying
closed-fixed
5
2004-04-15
2004-04-02
hperkins
No

A couple of minor user interface glitches in the current
production DrJava on WinXP.

1) alt-F4 doesn't do anything. For consistency with
other windows apps, it should cause the application to
quit (as cntrl-q does now).

2) When the "do you really want to quit" dialog pops up,
typing y or n doesn't do anything. One has to type alt-
y or alt-n. It'd be nice if y and n worked by themselves.

Hal

Discussion

  • Neal Horowitz

    Neal Horowitz - 2004-04-05

    Logged In: YES
    user_id=697810

    I'm looking in to the alt-F4 problem. That is definitely a
    bug, and has been present since the 2004-02-13 release. The
    other issue has to do with how Java treats accelerator keys;
    that is more properly a feature request, but I'll leave it
    here for now.

     
  • Neal Horowitz

    Neal Horowitz - 2004-04-05
    • labels: 388947 -->
     
  • Neal Horowitz

    Neal Horowitz - 2004-04-15
    • labels: --> User interface
    • summary: alt-F4 doesn't quit in windows, etc. --> alt-F4 doesn't quit in windows
    • milestone: --> 2: Annoying
    • assigned_to: nobody --> nrhorowitz
    • status: open --> closed-fixed
     
  • Neal Horowitz

    Neal Horowitz - 2004-04-15

    Logged In: YES
    user_id=697810

    I've found the source of the problem with alt-F4, and the
    fix will be in CVS soon. It has to do with the addition of
    granular undo -- to prevent problems with the undo logic,
    all key events were processed using the default behavior of
    a JEditorPane, then consumed. Apparently, a JEditorPane
    would not consume the edit by default, allowing another
    handler to consume it and close the window. In fact, it
    seems that we often consume events that we don't need to
    consume -- I removed several calls to consume the key event.
    Alt-F4 once again quits.

    Slightly longer-term, we should refactor the way we process
    key events. There is a method in JEditorPane called
    processComponentKeyEvent which is meant to be overridden for
    custom key handling; we should use that method instead of
    processKeyEvent itself.

    Anyway, the fix is being committed to cvs as I type. I'm
    closing this report; I opened up a separate feature request
    for the accelerator keys, Feature Request #935412.

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.