How to disable all UI actions and considerations in QT (handling the eventfilter layer of each widget, but it doesn't feel good, why not use qapplication)

Just finished a project, in the test has a problem: because of the existence of multithreading, when the speech recognition: If the user clicks on the Program Interface button or other to accept the Click event will signal the widget, the program will crash! Later try to solve from the multi-threaded, but more difficult, and then only from another way to solve, that is: when the speech recognition: Disable all user action!

The so-called disable all UI operation, on the handset and other handheld devices, especially pure touch screen devices, mainly refers to the prohibition of mouse operation! Of course: It may be forbidden to operate the keyboard, and so on. So how do you do that?

Method: We can intercept all event events of the Forbidden window and then throw them all away without processing. There are many ways to do this in Qt, and the more common way is to use the EventFilter event filter.

It is inevitable to mention the sequence of events in Qt, which passes through many layers () for me: The more layers I use are the layers of qapplication eventfilter, the eventfilter of each widget. The event () layer for each widget, and the layer where each of the widget's events are handled (this four-layer delivery order is in the past)

Here we only need to use the eventfilter of each widget! Can be written as follows:

BOOLIenableoperator =true; Mywidget::eventfilter (Qobject*obj, Qevent *Event){     if(Ienableoperator = =true)      {        if(Event->type () = =qevent::p aint) {           return false; }        Else        {             return true; }     }     Else     {        returnQwidget::eventfilter (obj,Event); }}

Then we only need to change the value of the variable ienableoperator to allow UI manipulation to be allowed!
//------------------------------------------------------------------------------------------------------------- ------------------------------
Here are a few points to note:
1: When the UI is disabled: it is not necessary to intercept all events, but to drain the paint drawing event (as we did above), because we just want to prohibit
UI action instead of updating the drawing again! For example: When doing speech recognition, we display a progress bar on the interface, and the value of the top is gradually increasing. When a UI action is forbidden: if
We intercepted the paint drawing event at the same time, and the progress bar was not updated! For these reasons, we need to leak the paint event!
2: Here is a special space: Qtextedit. When we were done with all the windows, we found that the UI operation of almost all windows was forbidden, except Qtextedit
No, cause the program will also occur crash! Later, after catching up with this problem, we found that the Qtextedit event delivery process is very different, whether under Windows or Symbian. For
All mouse events, which do not pass through any of its registered EventFilter event filters in the process, nor do they go through their own rewrite of the event (), but directly into their own
In the event handler (Mousepressevent (), and so on: ）！
For this: I have always felt that there is no reason to say, because other space, such as Qpushbutton are passing, but it does not pass! Maybe this is Qtextedit's other bug!!.
Later, we used the following method to disable the Qtextedit mouse event:
①: First, prepare a standard Qwidget object, set its transparency to 0.1, the same size as qtextedit, and position it as the location of the Qtextedit object, i.e.: Let's be a front and back
Overlapping relationships. Hide this window at the beginning!
②: When you need to disable Qtextedit UI operations (take our project as an example: when you start speech recognition), the translucent window created in front raise and show in the Qtextedit
The front of the qtextedit to shield itself. And when you want to allow Qtextedit UI action, hide it again!
In fact, the truth is also very simple: the Qtextedit block, the event will not be transmitted to it, and thus the ban fell. As we set the window transparency to 0.1, almost completely transparent,
The user simply does not experience that we have covered a window above.

//------------------------------------------------------------------------------------------------------------- ------------------------------
Add a bug:qtextedit about qtextedit this control behaves differently under Windows and Symbian!
Under Windows it behaves normally, but under Symbian: the slider slider length on the top of the scrollbar never changes, supposedly: the more the number of the screen the text occupies,
The shorter the length of the slider, the better. This makes it impossible for the user to swipe the slider to achieve the effect of flipping the screen.
But Symbian's qtextedit a couple of menus: when you normally press two arrows: it jumps out of a menu with a few options: The main thing is to scroll to
At the beginning, scroll to the end, and so on. It compensates for the constant size of the slider in this way. But I think this user experience is not always good with a slider.

http://blog.csdn.net/nrc_douningbo/article/details/5646247

How to disable all UI actions and considerations in QT (handling the eventfilter layer of each widget, but it doesn't feel good, why not use qapplication)