summaryrefslogtreecommitdiffstats
path: root/src/corelib/kernel/qeventdispatcher_win.cpp
Commit message (Collapse)AuthorAgeFilesLines
* QtBase: Windows: Replace some deprecated API usagesYuhang Zhao2022-08-031-8/+0
| | | | | | | | | | | | Microsoft recommends to use CoInitializeEx() and SetWindowLongPtr()/GetWindowLongPtr() in new code. Use COINIT_DISABLE_OLE1DDE to avoid overhead of initializing and using obsolete technology. Pick-to: 6.4 Change-Id: I9d16943e864d4487dd4f46fd9325579c298c52b9 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Remove manual declarations of qGlobalPostedEventsCount()Marc Mutz2022-05-181-2/+0
| | | | | | | | | ... in favor of including qabstracteventdispatcher_p.h, where needed. Keeps the code DRY. Change-Id: I5bee2e653cb29ffac2601ff03c952a4b3adbdb9c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Use SPDX license identifiersLucie Gérard2022-05-161-39/+3
| | | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Task-number: QTBUG-67283 Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* QEventDispatcherWin32: use SetCoalescableTimer for (Very)Coarse timersThiago Macieira2022-01-241-7/+41
| | | | | | | | The tolerance can be set per timer, unlike on Linux. Fixes: QTBUG-98316 Change-Id: I5e52dc5b093c43a3b678fffd16b788a30bcb9574 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Win32: always allow the event loop to be woken up by posted eventsVolker Hilsheimer2022-01-191-0/+2
| | | | | | | | | | | | | | | | | | | We set the wakeUps atomic to prevent multiple WM_QT_SENDPOSTEDEVENTS from being posted. However, this might happen right after the event processing thread cleared the atomic, but before it processed the previous WM_QT_SENDPOSTEDEVENTS message. In that case, we end up with a set atomic and an empty event queue, resulting in the event loop to block even though there are posted QEvents. To prevent that, always reset the atomic when we handle the WM_QT_SENDPOSTEDEVENTS message. In that case, we either call sendPostedEvents, or startPostedEventsTimer. The former already resets wakeUps; reset it in the latter as well. Fixes: QTBUG-99323 Pick-to: 6.2 6.3 5.15 Change-Id: I931c02be9c42b02e8ca20daba5059cd8185f0a37 Reviewed-by: Alex Trotsenko <alex1973tr@gmail.com>
* QEventDispatcher: Remove code dealing with Windows < 10Mårten Nordheim2021-07-281-13/+1
| | | | | | | It's not supported. Change-Id: I650a48f214bc4965b5e28f04e4f095273d7f9e5b Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QEventDispatcherWin32: suppress old {FD_CLOSE|FD_CONNECT} notificationsAlex Trotsenko2021-06-191-3/+10
| | | | | | | | | | As with other network events, we must also ignore these notifications until WM_QT_ACTIVATENOTIFIERS message is received. Fixes: QTBUG-82835 Pick-to: 6.2 6.1 Change-Id: I0740bf22e8d1cb0e8b4eba7fc1a27ffe669973ff Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QEventDispatcher(Win): Always honor interrupted status to avoid racesMårten Nordheim2021-03-111-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | There may be a race where e.g. thread 'B' is woken up by a queued invoke. At the same time thread 'A' asks 'B' to quit, which will set various atomics (some important ones are 'interrupt' in the dispatcher and 'exit' in the event loop), but it does _not_ try to send another wake since there is already an unhandled wake triggered by 'B' itself. Sadly 'B' reads the 'exit' atomic before 'A' updates it. Then, slightly before, 'B' sets 'interrupt' back to 0, 'A' write 1 to it, meaning 'A's interrupt is ignored. Then, since there is no interrupt, 'B' goes back to waiting for events, leaving the thread alive and running instead of quitting. Maybe this has unforeseen consequences (one consequence is that it will return and re-enter the event dispatcher once more, possible unnecessarily) Fixes: QTBUG-91539 Pick-to: 6.1 6.0 5.15 Change-Id: Ie6f861f42ffddf4817d5c8af2d764abe9d9103c2 Reviewed-by: Alex Trotsenko <alex1973tr@gmail.com> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QEventDispatcherWin32: get rid of the hook procedureAlex Trotsenko2021-02-251-28/+8
| | | | | | | | | | | | | | | | | | Instead of intercepting the WM_QT_SENDPOSTEDEVENTS message in the hook procedure, we can handle it at receive points, making qt_GetMessageHook() unnecessary. Including general performance improvements, this patch fixes the issue where some applications (e.g. Ableton Live) do not call a chain of nested hooks for plugins. Pick-to: 6.1 5.15 Fixes: QTBUG-90949 Change-Id: If8e96848392c6f10d45af2aac0567707d16af673 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Nuno Santos <nunosantos@imaginando.net>
* QEventDispatcherWin32Private: Get rid of TimerInfo struct listMaks Naumov2020-11-261-28/+20
| | | | | | | | | It was redundant with the timer info dictionary, and was even used where using the dictionary would have been more efficient. Change-Id: Ia656bf9b56c61e23df9f8743d8f8efbf65d37574 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Reviewed-by: Alex Trotsenko <alex1973tr@gmail.com>
* Adjust code format, add space after 'if'Zhang Sheng2020-11-161-1/+1
| | | | | | Change-Id: Ice081c891ff7f4b766f49dd4bd5cf18c30237acf Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io> Reviewed-by: hjk <hjk@qt.io>
* QWinEventNotifier: unlink from event dispatcherAlex Trotsenko2020-11-101-101/+1
| | | | | | | | | | | | | | | | | | | | | | | | Instead of multiplexing all notifications into a single Qt event for the event dispatcher, we can send 'WinEventAct' event directly for each notifier which activated. This trick improves the performance (esp. on a large number of events) and allows us to remove notifiers handling from the event dispatcher completely. As an alternative to sending Qt events, use of Windows' APC queue in conjunction with waking up the Qt event loop from within the Windows thread pool has been considered. However, that would lead to signal emission asynchronous to the Qt event loop's operation, which is not acceptable. Thanks to Oswald Buddenhagen for the proposed idea. [ChangeLog][QtCore][QAbstractEventDispatcher] The {un}registerEventNotifier() member functions have been removed. QWinEventNotifier is no longer needed to be registered in the event dispatcher. Change-Id: I140892fb909eaae0eabf2e07ebabcab78c43841c Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* Another round of replacing 0 with nullptrAllan Sandfeld Jensen2020-10-071-7/+7
| | | | | | | | | This time based on grepping to also include documentation, tests and examples previously missed by the automatic tool. Change-Id: Ied1703f4bcc470fbc275f759ed5b7c588a5c4e9f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* QAbstractEventDispatcher: change event dispatcher timer interval to qint64Liu Yang2020-09-211-1/+1
| | | | | | | | | Resolve remaining Qt6 TODO [ChangeLog][QtCore][QAbstractEventDispatcher] The signature of the abstract virtual registerTime function now takes a qint64 value for the interval parameter. Change-Id: I10166ad5cfb455edc404d465a3731ff094a8977e Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QWinEventNotifier: reinterpret 'int signaledCount' as a 'bool signaled'Alex Trotsenko2020-09-181-2/+2
| | | | | | | | | | | In fact, this variable can take only two values: 0 and 1. By interpreting its value as boolean, we can use relaxed store operations instead of atomic increments. This is safe, because it's guarded by 'activateEventNotifiersPosted' variable, which already provides a release/acquire semantic. Change-Id: If9adb7d022f1500ee7e8b61f336d8732f9b88d4c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* QEventDispatcherWin32: remove unused memberAlex Trotsenko2020-09-171-1/+1
| | | | | Change-Id: I9ec54aca7af190cd7ba7744ff52b05451dd7050a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QEventDispatcherWin32: create internal window on constructionAlex Trotsenko2020-09-161-36/+12
| | | | | | | | | | | | | | | | | When QCoreApplication object is instantiated, creation of the internal message window is delayed until QEventDispatcherWin32::processEvents() is called or socket/event notifier is registered. But, if the user uses a native event loop, posted events are not delivered and timers do not work. This problem was fixed in a4ac4b326318ed9034466305222280ed8d1651b5 for QWindowsGuiEventDispatcher in the same way. So, the risk of regression is minimal. Change-Id: I7bbb721d96046f64d21a7b0e553e46798b37189c Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Get rid of hasPendingEvents() and flush()Lars Knoll2020-09-061-9/+0
| | | | | | | They are unused. Change-Id: I77383f2be45551401ed9c2f88285511134cc8b0d Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Synchronize QEventDispatcherWin32::processEvents() with QCoreApplicationAlex Trotsenko2020-08-261-1/+3
| | | | | | | | | | | | | | | QCoreApplication has a special internal mechanism to control whether the event dispatcher should block after delivering the posted events. To handle queued connections in nested loops properly, we should use that functionality. Pick-to: 5.15 Fixes: QTBUG-85981 Change-Id: I124179a23b26a995cf95ed379e97bfa62c95f42a Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QEventDispatcherWin32: redesign event notifiers activationAlex Trotsenko2020-07-291-76/+62
| | | | | | | | | | | | | | The previous implementation multiplexed callback-based event notification into a single proxy event (cf. 85403d0af), which was in turn object-waited for (this was the case since the beginning of public qt history). It makes more sense to multiplex into a posted message, because that also works with foreign event loops that do not know anything about our event objects. Task-number: QTBUG-64443 Change-Id: I97945ac8b5d7c8582701077134c0aef4f3b5a18f Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove non-Qt6 compile time switches from QtCoreAllan Sandfeld Jensen2020-07-241-4/+0
| | | | | | | | We already manage to compile without this code, and none of it are full classes or separate functions suitable for qt5compat. Change-Id: I47facac7ec621cfc4b0b26214b7de37897443519 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* QEventDispatcherWin32: retrieve PM_REMOVE value as a bit flagAlex Trotsenko2020-06-031-1/+5
| | | | | | | | | | | | | | Windows unexpectedly passes PM_NOYIELD flag in wParam parameter to the hook procedure, if ::PeekMessage(..., PM_REMOVE | PM_NOYIELD) is called from the event loop. So, to ignore undocumented flag, we should interpret wParam as a bit field. Thanks to Robin Lobel for research. Pick-to: 5.15 Fixes: QTBUG-84562 Change-Id: Ib16d7d747aebc9a3628e4ee67478c4d3edeb96f1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* QEventDispatcherWin32: relax memory ordering on setting wakeUps flagAlex Trotsenko2020-04-171-1/+1
| | | | | | | | | | | | There is no need in 'acquire' operation for the next reasons: - wakeUps is simply used as an atomic boolean that does not require ordering with other loads or stores; - any of testAndSet...() always gets a latest version of wakeUps. Change-Id: Ica38fc62bc181166995946dee9d6887c71d87cec Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2020-04-061-33/+49
|\ | | | | | | | | | | | | Conflicts: src/corelib/kernel/qeventdispatcher_win.cpp Change-Id: I32db3f755577aefc15f757041367d6144f5e5c66
| * QEventDispatcherWin32: fix posted events deliveringAlex Trotsenko2020-04-031-33/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To avoid livelocks, posted events should be delivered when all pending messages have been processed, and the thread's message queue becomes empty. Although the logic of the previous patch is correct, it turned out that determining the moment when the message queue is really empty is not so simple. It is worth noting that the GetQueueStatus function sometimes reports unexpected results due to internal filtering and processing. Indeed, Windows docs say that "the return value from GetQueueStatus should be considered only a hint as to whether GetMessage or PeekMessage should be called". Thus, we cannot rely on GetQueueStatus in unambiguous logic inside the qt_GetMessageHook. To solve the problem, this patch introduces a guard timer which guarantees low priority processing for posted events in foreign loop. The wakeUps flag reset logic has also been changed to provide clearer synchronization of the Qt internal loop. Fixes: QTBUG-82701 Fixes: QTBUG-83151 Change-Id: I33d5001a40d2a4879ef4eb878c09bc1c0616e289 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* | QEventDispatcherWin32: unregister event notifiers on closeAlex Trotsenko2020-03-031-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When QEventDispatcherWin32::closingDown() is called, threadData->eventDispatcher is already nullptr and the application will no longer process the events. Thus, just as it works for socket notifiers and timers, it makes sense to disable all active event notifiers at this point. Otherwise, it seems possible that an object in signalled state can provoke a data race in the notifier's callback on 'edp' pointer, if QWin32EventDispatcher destructor is running simultaneously. Task-number: QTBUG-64152 Task-number: QTBUG-70214 Change-Id: I6e77f3eeca1b0ea639021e73b86798cba0200ebf Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* | Make QObjectPrivate::threadData a proper atomicGiuseppe D'Angelo2019-11-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QObjectPrivate::threadData used to be a QThreadData *, and was read and written from multiple threads without proper synchronization. As an example, it was read from QCoreApplication::postEvent and written from QObject::moveToThread, therefore causing UB. Port threadData to a proper atomic, removing the races. Fix all usage points. In general, QObject is documented to be simply reentrant, not thread-safe, and certain bits (e.g. timers, moveToThread) are not even reentrant. The reasoning therefore is that a given QObject's threadData is not supposed to be touched by multiple threads without some synchronization happening elsewhere, and therefore relaxed loads should be sufficient. As drive-by change: refactor QCoreApplication::postEvent. It was particularly subtle, because it had a loop using a volatile to cope with the possibility of the receiver object switching thread while we tried to lock its thread's event queue. However, volatile does not achieve any synchronization, so drop it, and refactor the algorithm using better locking primitives. Put this algorithm in a common place, and also reuse it from removePostedEvents, which was lacking any synchronization. Change-Id: Icc755f7eb418ff54b33db4bdd87fd8eaf4e82c7a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | QEventDispatcherWin32: unify input checks in {un}register...()Alex Trotsenko2019-11-131-18/+18
|/ | | | | | | | | | | | | | The event manager has a family of the functions for registering sockets notifiers, event notifiers, and timers. To ensure efficient debugging, it would be useful to have one approach regarding input parameters validation for the entire set of that functions. Based on registerSocketNotifier() implementation, this patch offers the same debugging principles for QWinEventNotifier and QTimer. Some debug messages have also been refined. Change-Id: I1418ef43c51f7b794462b5e9c8a849633e0c60f9 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QEventDispatcherWin32: avoid livelock in a foreign event loopAlex Trotsenko2019-08-291-32/+35
| | | | | | | | | | | | | | | | | | | | | | | | According to Windows docs, GetMessage() function retrieves the messages from the input queue in defined order, where posted messages are processed ahead of input messages, even if they were posted later. Therefore, if the application produces a posted event permanently, as a result of processing that event, user input messages may be blocked due to hard CPU usage by the application. It's not a problem, if an internal Qt event loop is running. By calling sendPostedEvents() on the beginning of processEvents(), we are sending posted events only once per iteration. However, during execution of the foreign loop, we should artificially lower the priority of the WM_QT_SENDPOSTEDEVENTS message in order to enable delivery of other input messages. To solve the problem, it is proposed to postpone the WM_QT_SENDPOSTEDEVENTS message until the message queue becomes empty, as it works for the internal loop. Task-number: QTBUG-77464 Change-Id: I8dedb6837c6fc41aa6f497e67ab2352c2b4f3772 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Remove hook handling code from QEventDispatcherWin32Joerg Bornemann2019-07-021-42/+1
| | | | | | | | | | | Since commit 6a7cea64 qt_GetMessageHook is effectively a no-op, and we can remove the complete hook handling code. Change-Id: I90383c0c09c2b0f1d715872de5f9519a879d9bae Reviewed-by: Alex Trotsenko <alex1973tr@gmail.com> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Remove unused qmutexpool_p.h includesMarc Mutz2019-06-291-1/+0
| | | | | Change-Id: Ic5f56b12953f2e42d94f6e6c14fac166c0c75539 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Port from QAtomic::load() to loadRelaxed()Giuseppe D'Angelo2019-06-201-7/+7
| | | | | | | | | | | | | | | Semi-automated, just needed ~20 manual fixes: $ find \( -iname \*.cpp -or -iname \*.h \) -exec perl -pe 's/(\.|->)load\(\)/$1loadRelaxed\(\)/g' -i \{\} + $ find \( -iname \*.cpp -or -iname \*.h \) -exec perl -pe 's/(\.|->)store\(/$1storeRelaxed\(/g' -i \{\} + It can be easily improved (e.g. for store check that there are no commas after the opening parens). The most common offender is QLibrary::load, and some code using std::atomic directly. Change-Id: I07c38a3c8ed32c924ef4999e85c7e45cf48f0f6c Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
* QEventDispatcherWin32: rework sending of posted eventsAlex Trotsenko2019-05-251-68/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since its initial implementation, QEventDispatcherWin32 manages a delivery of the posted events from the window procedure through WM_QT_SENDPOSTEDEVENTS message. That makes the implementation quite difficult and unclear. As a result, posted events get stalled, in case of using nested event loops or other recursion. The proposed solution is to send posted events at the beginning of processEvents() only once per iteration of the event loop. However, in case of using a foreign event loop (e.g. by opening a native modal dialog), we should leave the emission in the window procedure, as we don't control its execution. Task-number: QTBUG-74564 Change-Id: Ib7ce85b65405af6124823dda1451d1370aed9b1a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QtCore: use qUtf16Printable and %ls, qErrnoWarning()Marc Mutz2019-05-291-3/+3
| | | | | | | | | | | | ... instead of qPrintable(), %s, and explicit qt_error_string(). Saves 2KiB in text size on optimized Linux AMD64 GCC 9.1 builds. Change-Id: I98b6717da1ed1b678f01167d704a96f10da47966 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Update outdated comment in QEventDispatcherWin32::processEventsJoerg Bornemann2019-05-231-1/+1
| | | | | | | | | | | | | The reason for the explicit qt_GetMessageHook call is not related to Windows CE anymore. It is a work-around used by the Direct2D integration. Change-Id: I489665741fc673ab9d29b35a0c02c51f2a9e9288 Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
* Widen out parameter "result" of the native event filters for Qt 6Friedemann Kleint2019-03-221-0/+4
| | | | | | | | | LRESULT on Windows 64 is a 64bit type, adapt filter functions of QAbstractNativeEventFilter and QAbstractEventDispatcher accordingly. Fixes: QTBUG-72968 Change-Id: Ie53193e355f0b8e9bd59fa377f43e2b4664a2ded Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-02-281-5/+5
|\ | | | | | | Change-Id: Icc9b061c56e969756f0351c936cdeb8063c86079
| * Make the QEventDispatcherWin32Private::interrupt flag atomicThiago Macieira2019-02-271-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Not entirely sure that this solves the problem reported in the bug report, but here's the theory: the loop 633 while (!d->interrupt) { ... 710 } has few calls that recurse back, so the compiler optimizer can assume that the variable remains unchanged (not interrupted) in most of the branches. Additionally, it can assume the variable did not change from there to 712 // still nothing - wait for message or signalled objects 713 canWait = (!retVal 714 && !d->interrupt 715 && (flags & QEventLoop::WaitForMoreEvents)); Which causes canWait to be true, despite having been interrupted by another thread. Changing to an atomic does not force the reloading of the variable (strictly speaking, would need volatile, but all atomic implementations do reload now), but it solves the problem of data race, which was UB. The equivalent variable in the Unix event dispatcher is atomic (commit 49d7e71f77f899c05e4b5187e8834dfcbddf4505 from 2013). I've reordered the bool members so they're all together and reduce the amount of padding in this class. Fixes: QTBUG-72438 Change-Id: I4ac1156702324f0fb814fffd156f290df94dc4c7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Windows: improve QTimer::remainingTime when called before processEventsChristian Andersen2019-01-281-2/+8
|/ | | | | | | | | | | | | | | | | | | | | This checks that intenalHwnd in QEventDispatcherWin32::remainingTime is initialized. If calling remaningTime, before createInternalHwnd is called, the timeout member in the WinTimerInfo struct is not initialized and contains a random value. This adds a check for that and in that case returns the requested timer interval as the timer has not yet been started. createInternalHwnd is called on the first request to process events. It also adds a test for checking the remaining time. But the issue can only be seen if solely running the remainingTimeInitial test in tst_QTimer. If running the test along side another test the other test likely calls processEvents indirectly, which hides the issue. I don't know if this is an issue in practice (the bug has been there for as long a the git history goes back, 2011), but it causes the basic_chrono test to fail if run as the only test. Change-Id: I05c35105da778912dedf8d749aa7c953841d986e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Windows code: Fix to prefer ranged-for, as clang-tidy advisesFriedemann Kleint2018-09-021-5/+2
| | | | | | | Change-Id: Id9bb21855ae832cdbbc456326226ec72b634672e Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Luca Beldi <v.ronin@yahoo.it> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Windows code: Fix clang-tidy warnings about else after jumpsFriedemann Kleint2018-09-021-28/+34
| | | | | | | | | Replace by switch() where appropriate, remove else and unindent code or simplify the return value. Change-Id: Ie988b9068a9579ae5a899b3765e43aad480b564e Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Windows code: Fix clang-tidy warnings about C-style castsFriedemann Kleint2018-08-301-6/+6
| | | | | | | | | | | Replace by reinterpret_cast or const_cast, respectively. Use auto when initializing a variable to fix Clang warnings about repeating the type name, do minor tidying along the way, and a few conversions of 0 or NULL to nullptr. Change-Id: Ieb271a87ddcf064f536e1ff05d23b1e688b1b56a Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Windows: Fix QEventLoop::ExcludeUserInputEvents for pointer eventsFriedemann Kleint2018-08-031-13/+18
| | | | | | | | | | | | Factor out the check for user input events from QEventDispatcherWin32::processEvents() to a small helper and add pointer messages (by value as to avoid MinGW issues). Task-number: QTBUG-60437 Task-number: QTBUG-69687 Change-Id: I38bf227f862fcc44177a5027cafe1df49a10a919 Reviewed-by: Andre de la Rocha <andre.rocha@qt.io> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Fix asserts and crashes in QWinEventNotifier activation loopJoerg Bornemann2018-01-261-9/+14
| | | | | | | | | | | | | | | | | | | The backwards iteration was done under the assumption that the only valid modification of the winEventNotifierList in a slot connected to activated() would be the removal of the notifier itself. This is wrong. Instead, iterate forwards, like before 85403d0a, and check the index against the current list size in every iteration. This ensures that we do not run out of bounds while the list is modified. Also, retry the activation loop if the list was modified by a slot connected to activated(). This ensures that all notifiers with signaled handles are activated. Task-number: QTBUG-65940 Change-Id: I25f305463b9234f391abc51fe0628d02f49b6931 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
* Fix QWinEventNotifier for auto-reset eventsJoerg Bornemann2017-10-151-1/+2
| | | | | | | | | | | | | Auto-reset events are automatically reset to non-signaled when we get notified about the signaled state. This implies that we cannot check the event state again in activateEventNotifiers. Instead, store the signaled state in a QAtomicInt and test and decrement that. This amends commit 85403d0a. Task-number: QTBUG-63555 Change-Id: I0adee3d2929783f98d91060f9106c8b5266d72fa Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
* Merge remote-tracking branch 'origin/5.9' into devOswald Buddenhagen2017-08-021-1/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/plugins/platforms/xcb/qxcbconnection.h src/plugins/platforms/xcb/qxcbconnection_xi2.cpp src/plugins/sqldrivers/sqlite/qsql_sqlite.cpp src/plugins/styles/mac/qmacstyle_mac.mm src/widgets/widgets/qdockarealayout.cpp src/widgets/widgets/qmainwindow.cpp src/widgets/widgets/qmainwindowlayout.cpp src/widgets/widgets/qmainwindowlayout_p.h tests/auto/corelib/tools/qlocale/tst_qlocale.cpp tests/auto/other/macnativeevents/BLACKLIST tests/auto/widgets/widgets/qmenu/BLACKLIST Change-Id: Ic8e724b80a65e7b1af25511b0e674d209265e567
| * QEventDispatcherWin32: Check for WM_QT_SOCKETNOTIFIER on internal window onlyFriedemann Kleint2017-07-291-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | Restrict the checking to the internal window handle to prevent it being thrown off by other WM_USER messages used by applications. Complements change 124b9a6ff89da8be83a256135ec6c4d0603e9a6f. Task-number: QTBUG-62083 Change-Id: Ifb1b00e4ff70cb7e53873943e46cea0d72ff6257 Reviewed-by: Alex Trotsenko <alex1973tr@gmail.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Support more than 62 instances of QWinEventNotifier, take 2Joerg Bornemann2017-07-301-26/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QWinEventNotifiers were limited to 62 instances, because of WaitForMultipleObject's limitation to MAXIMUM_WAIT_OBJECTS - 1 handles. Use the RegisterWaitForSingleObject API which does not have this restriction and executes waits in threads managed by the system. A central manual reset event per event dispatcher is signaled in the RegisterWaitForSingleObject callback and waited for in the event loop. Task-number: QTBUG-8819 Change-Id: I3061811c18e669becf9de603bbdd7ba96e4d2fcd Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* | Revert "Support more than 62 instances of QWinEventNotifier"Liang Qi2017-06-281-41/+26
| | | | | | | | | | | | | | | | | | | | It breaks sth in QLocalSocket which is used in QtRemoteObject. This reverts commit 5c6210e3452f78cab2f58887e747eb5cb2501f70. Task-number: QTBUG-61668 Change-Id: Ib11890923773496e5d998b7709ef93b0a839a759 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* | Support more than 62 instances of QWinEventNotifierJoerg Bornemann2017-06-261-26/+41
|/ | | | | | | | | | | | | | | | | QWinEventNotifiers were limited to 62 instances, because of WaitForMultipleObject's limitation to MAXIMUM_WAIT_OBJECTS - 1 handles. Use the RegisterWaitForSingleObject API which does not have this restriction and executes waits in threads managed by the system. A central manual reset event per event dispatcher is signaled in the RegisterWaitForSingleObject callback and waited for in the event loop. [ChangeLog][QtCore][QWinEventNotifier] QWinEventNotifier is not restricted to 62 instances anymore. Task-number: QTBUG-8819 Change-Id: I2c749951453a4b699cc50dada0d6017440b67a4a Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-09 00:32:29 +0000