I am looking for an alternative to QThread and QProcess to perform blocking operations in main GUI thread in such a way that whenever user presses key during processing, corresponding QKeyEvent is discarded. I paste a snippet of code that presents what I want to achieve. But it does not work as I expect, I explain later why.

Qt Code:
  1. void MyWindow::keyPressEvent(QKeyEvent* keyEvent)
  2. {
  3. if (keyEvent->key() == Qt::Key_F1)
  4. {
  5. PleaseWait waitDlg; // a window covering whole screen and doing nothing
  6. waitDlg.SetDetails("Please wait while processing...");
  7. waitDlg.setWindowModality(Qt::ApplicationModal);
  8. waitDlg.show();
  9. QCoreApplication::processEvents();
  10.  
  11. int status = processData1();
  12. QCoreApplication::processEvents();
  13.  
  14. if (status)
  15. {
  16. if ( message_box::ask("Question") ) // it opens modal dialog and calls exec()
  17. processData2();
  18. else
  19. processData3();
  20.  
  21. QCoreApplication::processEvents();
  22. }
  23.  
  24. processPostActions();
  25. }
  26. }
To copy to clipboard, switch view to plain text mode 

Unfortunately when user presses keys during processData1() execution, QKeyEvent objects are not generated, that's why calling QCoreApplication:rocessEvents() does not have any effect except execution of paint events. QKeyPress events are generated, probably in exec() of message_box. This results in QKeyEvent being handled in message_box dialog - it is unexpected behaviour.

I run my application on Linux on ARM which is pretty slow in a comparison to PC. That's why similar problem occurs whenever I open new dialogs. You can press key which triggers opening of new dialog and before it is actually displayed (it can take up to 1s) press another key, which will be handled in the new dialog - it is again unexpected and not acceptable behaviour.

Is there a way to affect somehow QT keyboard driver (or however is called the thing which creates QKeyEvents) and erase all queued input keys that come from Linux keyboard driver?