KeyListener Issues in Pop-Up DocumentWindow

Windows
1

Hello! I am attempting to implement a piano roll editor in a JUCE application as a pop-up window, and currently, I cannot get key presses to work properly. I am attempting to adapt this code into my project as a pop-up window. Almost everything I’ve done is basically copied and pasted into my project with minimal changes, except each #ifndef LIB_VERSION is commented out.

The relevant code for the NoteGridComponent, which is where I’m listening for key presses is here:

NoteGridComponent::NoteGridComponent(GridStyleSheet &sheet) : styleSheet(sheet) 
{
    //...
    addKeyListener(this);
    setWantsKeyboardFocus(true);
    //...
}

/*---------------------------------------------------------------------*/

bool NoteGridComponent::keyPressed(const juce::KeyPress &key, Component *originatingComponent) 
{

    if (styleSheet.disableEditing) 
    {
        return true;
    }
    
    if (key == juce::KeyPress::backspaceKey) 
    {
        deleteAllSelected();
        sendEdit();
        return true;
    } 
    
    else if (key == juce::KeyPress::upKey || key == juce::KeyPress::downKey) 
    {
        bool didMove = false;
        for (auto nComp: noteComps) {
            if (nComp->getState() == NoteComponent::eSelected) 
            {
                NoteModel nModel = nComp->getModel();

                (key == juce::KeyPress::upKey)
                    ? nModel.setNote(nModel.getNote() + 1)
                    : nModel.setNote(nModel.getNote() - 1);

                nModel.sendChange = sendChange;
                nComp->setValues(nModel);
                didMove = true;
            }
        }
        if (didMove) 
        {
            sendEdit();
            resized();
            return true;
        }
    } 
    else if (key == juce::KeyPress::leftKey || key == juce::KeyPress::rightKey) 
    {
        bool didMove = false;
        const int nudgeAmount = currentQValue;
        for (auto noteComponent: noteComps) 
       {
            if (noteComponent->getState() == NoteComponent::eSelected) 
           {
                NoteModel noteModel = noteComponent->getModel();

                (key == juce::KeyPress::rightKey)
                    ? noteModel.setStartTime(noteModel.getStartTime() + nudgeAmount)
                    : noteModel.setStartTime(noteModel.getStartTime() - nudgeAmount);

                noteModel.sendChange = sendChange;
                noteComponent->setValues(noteModel);
                didMove = true;
            }
        }
        if (didMove) 
        {
            sendEdit();
            resized();
            return true;
        }
    }
    return false;
}

As far as I can tell, the NoteGridComponent is receiving keyboardFocus, but the keyPressed method is not getting called at all. NoteGridComponent is currently a child of one of the app view components, and keyboard focus is being grabbed when the window is made visible. If anyone has any insight into this issue, it would be greatly appreciated. Thanks!

2

Just off the top of my head, if the NoteGridComponent is based on a Component class, you should be able to ditch the KeyListener, and just override:

virtual bool Component::keyPressed ( const KeyPress & key )

3

If you want my advice, kill your popupmenu’s and replace them with sliding panel components which are a part of your main UI hierarchy.

Popupmenu’s are the devil and should not be being used. Every popupmenu is a new Window handle and associated device context switch!

They incur significant performance and resources costs on Windows (and also MacOS, it should be noted!), and are really a nasty bit of UI technology from the 80’s that just need to die, already. Just don’t use them. Seriously, your life will be far simpler if you just add sliding inner panels to your main UI and render things there.

A sliding panel component within an inner ScrollView of your main UI is going to provide a much better user experience, and as well be a far more future-proof user interaction going forward.

Plus, you won’t have all these hangover issues of event focus, message loop insertion/deletion, and on and on.

Disclaimer: I have eradicated popumenu’s in my project and the sky is blue, the sea is fresh, the birds are singing, and performance - and as well, user experience - is in the stratosphere.

4

I don’t think the OP is talking about popup menus here…

5

I am attempting to implement a piano roll editor in a JUCE application as a pop-up window,

pop-up menu/piano roll editor?

Any new window context is what prompted my comment.. anyway, window management in cross-platform contexts is an interesting conundrum .. especially vis a vis keyboard/no-keyboard environments, window/no-window environments .. all I wanted to say is there is a way to use ‘panels’ instead of popups which is generally a bit more future proof … apologies for my misunderstanding.

1 Like
6

Right now, it’s a pop-up window. More specifically, I’m having my app create a new DocumentWindow, which will be added as a child of the app and then will be added to the desktop. The piano roll editor exists inside of there. Maybe “pop-up window” is a little misleading, but essentially I mean a secondary window that will hold more options, with just a close button.

Just off the top of my head, if the NoteGridComponent is based on a Component class, you should be able to ditch the KeyListener, and just override:
virtual bool Component::keyPressed ( const KeyPress & key )

Thanks! I actually didn’t know Component had it’s own keyPressed method, I’ll look into this.

all I wanted to say is there is a way to use ‘panels’ instead of popups which is generally a bit more future proof

I haven’t considered this before. How would this look compared to using a new DocumentWindow? What classes should I look at for this?

I appreciate your guys’ help! I was worried I wouldn’t get a quick response. :slight_smile:

7

An integrated ‘panel’ which opens and closes in your main UI is really just another Component, and you can create these kinds of panels which slide and adjust dynamically quite easily once you master FlexBox. To my mind, FlexBox is the anti-dialog, the solution to modal stress.

The reason I suggest this is, modal dialogs and popups add complexity to event handling, and imho these days audio users are more responsive to sliding panels that integrate well with the rest of the UI, than popup windows and such, which tend to obscure the UI.

But of course, ymmv..

1 Like
8

I appreciate your insight! This makes a lot of sense actually, and it seems like it would greatly simplify event handling, like you say. I will look into this option some more as the project continues. I am VERY new to JUCE, though I’ve known about and have wanted to get into it for a while. I’m giving myself a crash course for my undergraduate capstone right now. Thank you both again!

9

Another solution similar/but different than a panel, is to make fake dialog components, which are actually part of the main component, and at the top of the z order. You make it fill the entire main component, with either a transparent, or semi-transparent fill, which keeps the ui interaction constrained to the ‘dialog’, and then center the actual component for the dialog in the center of that.

But, as @ibisum points out, the panel is easier to adopt in mobile.

1 Like