[Interest] QWindowSystemInterface::flushWindowSystemEvents() causes signals to be handled in the wrong order?

[Frans Klaver]

On Wed, Aug 7, 2013 at 10:37 AM, R. Reucher <rene.reucher at batcom-it.net> wrote:
> On Wednesday 07 August 2013 10:19:34 Michel Rosien wrote:
>> In my application a QWidget can be created/destroyed using a toggle button.
>> If the button is pressed rapidly, so many 'on' - 'off' - 'on' - 'off'
>> signals are being send, it can occur that an 'on' signal is handled while
>> an 'off' handler is still in progress (because the 'off' handler deletes
>> the widget)
>>
>> Am I forced to use deleteLater instead of delete for a QWidget in this
>> case? I would like to prevent this.
>>
>> Any thoughts?
> It sounds as if there can only be one instance of this QWidget at a time... so
> why not keep a pointer to it, initialized to NULL / set to NULL after
> deletion, so your on/off handlers could check that before acting (delete only
> if *not* NULL / create only *if* NULL).

While this sounds like a good idea to start with, there might be some
more serious implications of the nested event loop in more complex
systems. QWindowsWindow is now, through flushWindowSytemEvents(),
doing exactly what has been marked as evil by Qt devs in the past.

In any case, apparently calling flush was introduced in relation to
QTBUG-26903 (which is about the initial window placement) in patch set
5[2]. It features a note stating that it "looks unrelated but
hopefully fixes the CI problems". It hasn't been removed afterwards. I
guess this suggests this line could be removed without causing any
trouble? Could Shawn or Gunnar comment on this?

Cheers,
Frans

[1] http://bugreports.qt-project.org/browse/QTBUG-26903
[2] https://codereview.qt-project.org/#patch,sidebyside,44080,5,src/plugins/platforms/windows/qwindowswindow.cpp