Ok, just had another look at this and it turns out that QWidget::event() doesn't actually block shift-tab. sorry for misinforming you, looked over the source a bit to hastily.
I've done some testing and found out that shift-tab is not reported as Qt::Key_Tab, but as Qt::Key_Backtab (at least on my system, debian linux with kde). So all you have to do is check for Qt::Key_Backtab:
	
	- switch(e->key()) 
-     { 
-     case Qt::Key_Tab: 
-         if(textCursor().selectionEnd() - textCursor().selectionStart() > 0) 
-         { 
-             bool shiftHeld = e->modifiers() & Qt::ShiftModifier; 
-             tabPressedEvent( shiftHeld ); 
-         } 
-         break; 
-   
-     case Qt::Key_Backtab: 
-         tabPressedEvent( true ); 
-         break; 
-     } 
        switch(e->key())
    {
    case Qt::Key_Tab:
        if(textCursor().selectionEnd() - textCursor().selectionStart() > 0)
        {
            bool shiftHeld = e->modifiers() & Qt::ShiftModifier;
            tabPressedEvent( shiftHeld );
        }
        break;
    case Qt::Key_Backtab:
        tabPressedEvent( true );
        break;
    }
To copy to clipboard, switch view to plain text mode 
  Where I kept the shift modifier check, just in case there is a system which does not use backtab to identify shift+tab.
If you need to dissable the behavour that tab/shift+tab changes focus to the next widget you will still need to re-implement event() however. The article Events and Event Filters has an example on this (which is perfect for you ).
).
hope this helps and happy coding .
.
				
			
Bookmarks