Filtering shortcut in eventFilter not working



  • Hi all,
    I'm trying to block/filtering shortcuts regarding some condition in a event filter method at application level, but it has no effect.

    (pseudo) code showing what i'm doing:

    bool Application::eventFilter(QObject *obj, QEvent *event)
    {
    if(event->type() == QEvent::ShortcutOverride)
            {
             QAction* action=actionWithShortcut(obj,event); // get the action 
    
              if(action)
                {
                 action->setEnabled(false); // disable it
                 return true;  // has no effect
                }
    ...
    

    anyway, the shortcut is triggered :(

    My goal is to intercept shortcuts before there're triggered, I thought an event filter could be a good way but to no avail.

    Any idea ?


  • Lifetime Qt Champion

    Hi,

    Shouldn't that be QEvent::Shortcut ?



  • Hi @SGaist

    I tried allready, such event never occured ...

    For a single key stroke, I see two ShortcutOverride event:

    shortcut override "Couper" "Ctrl+X" TextEdit(0x7f8fae45a5d0)
    shortcut override "Couper" "Ctrl+X" TextDocWindow(0x7f8fae459c80)
    

    Maybe I need to filter in the widgets too ?


  • Lifetime Qt Champion

    Something's not clear, why do you want to disable the action that is associated with the shortcut when you actually call the shortcut ?



  • @SGaist
    I wondered that earlier too :) I think you can ignore the action->setEnabled(false); // disable it, I read the OP's question as why does return true; // has no effect have no effect?



  • @SGaist said in Filtering shortcut in eventFilter not working:

    why do you want to disable the action that is associated with the shortcut when you actually call the shortcut ?

    Yes and I want that the action was not triggered (logical ?)
    Why ? yes I know, it's not the common way to do.
    Actually, I try to implement a responder chain for the menu management.

    What I see, is that the action method is called so I need an extra test in it:

    void Application::menuAction(QAction* action)
    {
        // validateAction dans event filter sans effet
    // test action state
        if(!action->isEnabled()) return;
    ...
    

    In addition on Mac, the menu is flashing but no action takes place in fact.
    But if I do the same key stroke a second time, the action is not triggered, so the action state (disabled) is not take in account immediately in the event filter.
    That's why I would like to discard the shortcut event.


  • Lifetime Qt Champion

    Again, that sounds counter-intuitive and convoluted. Why not just disable the action when it should not be used ?

    What chain do you want to build with that ?



  • It turns out, that the filter works well, if I return yes in the event filter, the shortcut is not propagated to the TextEdit, so far so good.

    The final question is, who triggers the action ?

    @SGaist
    The "Responder Chain" is a very good paradigm for menu management, unfortunatly not easy to implement in Qt.


  • Lifetime Qt Champion

    Unless we have a different definition of Responder Chain, it's what Qt implements. Hence my question about what you are trying to achieve.



  • @SGaist said in Filtering shortcut in eventFilter not working:

    Unless we have a different definition of Responder Chain, it's what Qt implements.

    I agree, but does it apply with menu actions ?
    What I want to do, is the same thing as validateMenuItem on MacOS.
    validatemenuitem

    On Mac, this method is called before a menu appears (menuAboutToShow on Qt), but also before a shortcut is triggered, allowing to validate the menu at the time the action occurs.
    That what I'm trying to do with a eventFilter.


  • Lifetime Qt Champion

    With Qt, you usually trigger a signal when conditions are met that you connect to the setEnable of the QAction you want. Or you modify the action object directly.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.