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?
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)
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?
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?
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();
}
Yes, I’m on that bug at the moment, will check in a fix shortly…