Alt-F4 ignored when TextEditor has focus


#1

The heading pretty much says it all. Alt-F4 appears to get swallowed up by the TextEditor if you have a TextEditor on a window and it has the focus. This is a problem on Windows because Alt-F4 should typically always close an app. Any ideas how to work around this problem? Perhaps I’m missing something simple?


#2

That’s surprising, I’d have expected it to ignore it. I guess it needs a little special handling in the TextEditor to make sure it doesn’t get seen as a keystroke. How about this (around line 2060):

else if (key.isKeyCode (KeyPress::escapeKey)) { newTransaction(); moveCursorTo (getCaretPosition(), false); escapePressed(); } #if JUCE_WIN32 else if (key == KeyPress (KeyPress::F4Key, ModifierKeys::altModifier, 0)) { return false; } #endif else if (key.getTextCharacter() >= ' ' || (tabKeyUsed && (key.getTextCharacter() == '\t'))) {

(I’m on my mac right now, so haven’t tried it)


#3

That didn’t fix it. It is my understanding that Alt-F4 is intercepted by Windows and the app receives a WM_CLOSE. Looking in juce_win32_Windowing.cpp I see this code:

case WM_CLOSE:
    if (! component->isCurrentlyBlockedByAnotherModalComponent())
        handleUserClosingWindow();

    return 0;

So is the TextEditor considered a blocking modal component?


#4

No, that’s not relevant at all. It must be because the keypress is being consumed somewhere before the OS gets to see it, and I’m surprised my suggestion didn’t work. Maybe stick a breakpoint in that TextEditor::keyPressed method and see what happens?


#5

Okay, I traced through the code and the following function in TextEditor.cpp is causing the Alt-F4 to get tossed:

bool TextEditor::keyStateChanged() { // (overridden to avoid forwarding key events to the parent) return ! ModifierKeys::getCurrentModifiers().isCommandDown(); }


#6

Yes, I’m on that bug at the moment, will check in a fix shortly…