gpt4 book ai didi

c++ - Qt blockSignals 没有阻止第一次额外点击

转载 作者:行者123 更新时间:2023-11-30 02:31:44 24 4
gpt4 key购买 nike

我试图通过在连接到按钮的插槽函数中使用 QObject 的 blockSignals 方法,在 QPushButton 上进行额外的点击,但什么都不做。然后,我将发射一个排队的连接信号,该信号连接到一个插槽,该插槽可以解锁按钮的信号。

我的想法是,像数据库操作这样的阻塞操作(由下面代码中的 sleep 调用表示)可能会导致用户额外单击按钮。我解决这个问题的方法是在第一次点击后阻止按钮的信号,这样在阻止操作期间累积的额外点击将什么都不做,自发事件队列将完成,然后发布的事件队列将处理排队的信号将取消阻止按钮并将应用程序返回到其正常状态。

我的问题是第一个点击处理,但是第一个额外的点击,应该被阻止,却意外地处理了。随后的额外点击没有任何作用。

代码如下:

#ifndef MAINWINDOW_H
#define MAINWINDOW_H

#include <QMainWindow>
#include <QPushButton>

class MainWindow : public QMainWindow
{
Q_OBJECT

public:
MainWindow(QWidget *parent = 0);
~MainWindow();

private:
QPushButton *btn;

signals:
void delayed_unblock();

private slots:
void doStuff();
void unblock();
};

#endif // MAINWINDOW_H

...以及其余代码:

#include "mainwindow.h"
#include <QDebug>
#include <QTest>

int num = 0;

void MainWindow::doStuff() {

qDebug() << btn->signalsBlocked();
qDebug() << btn;
qDebug() << sender();
qDebug() << num++;
btn->blockSignals(true);
QTest::qSleep(5000);
emit(delayed_unblock());
}

void MainWindow::unblock() {

btn->blockSignals(false);
}

MainWindow::MainWindow(QWidget *parent)
: QMainWindow(parent),
btn(new QPushButton("foo"))
{
connect(btn, &QPushButton::clicked, this, &MainWindow::doStuff);
connect(this, &MainWindow::delayed_unblock,
this, &MainWindow::unblock,
Qt::QueuedConnection);

setCentralWidget(btn);
}

如果我快速单击按钮 4 次,调试控制台会执行以下操作:

false
QPushButton(0x3e8840)
QPushButton(0x3e8840)
0
false
QPushButton(0x3e8840)
QPushButton(0x3e8840)
1

我期待输出只是

false
QPushButton(0x3e8840)
QPushButton(0x3e8840)
0

因为,据我所知,第一次点击会导致同步插槽调用,这会阻止任何后续按钮信号的发生。在我的案例中,随后的信号源自自发事件队列中的鼠标单击事件。看起来,所有额外的点击都应该被阻止,但第一次额外的点击仍然可以通过。

如果有帮助,请单击一次,等待 3 秒,然后快速单击 3 次会导致与上述相同的结果。

我的编译器是 MSVC 2015。

最佳答案

深入研究 Qt 的分派(dispatch)机制可以了解按什么顺序发生了什么。由此很明显为什么会出现这种奇怪的行为。

从回溯中,我深入研究了 Qt 用于调度事件的 glib 2.0 的 g_main_context_dispatch。

在这个函数中,事件被分配到不同的组(队列)中。例如。首先是所有发布的事件,然后是所有 X11/Windows 事件,等等。

请注意,包含按下和释放事件的单击鼠标通常会导致两个连续的队列,因为它们的处理速度非常快。

意味着“按下”进入队列,这个包含这个单一事件的队列或多或少立即被处理,“释放”进入下一个队列并且也被立即处理(总是在程序触发的一些发布事件之后或所以)。

只有当某些事情(比如 qSleep())的处理需要更长的时间时,队列中每组可能包含多个事件。

我设置了三个断点并在主窗口和按钮上安装了一个事件过滤器。这样就可以看到一切是如何相互作用的。

gdb$ info breakpoints

Num Type Disp Enb Address What
2 breakpoint keep y 0xb6d41db2 <g_main_context_dispatch+578>
breakpoint already hit 549 times
silent
p "dispatch"
continue

4 breakpoint keep y 0xb6d41bdd <g_main_context_dispatch+109>
breakpoint already hit 546 times
silent
p $ebp
continue

5 breakpoint keep y 0xb6d41bc9 <g_main_context_dispatch+89>
breakpoint already hit 551 times
silent
p "leaving"
continue

请注意,我在所有断点命令中都放置了“continue”。所以调试在任何时候都没有阻止应用程序。

连续点击四次(qSleep()中的三次)的结果如下:

// Dispatch function entered, one queue with events available
$1528 = (void *) 0x1

// dispatching results in the pressEvent received by the button
$1529 = "dispatch"
"QPushButton(0x809d128) press"

// dispatch function left, the spontaneous event queue
// contained only the mouse press
$1530 = "leaving"

// again entering with events in 2 queues, no idea what for
$1531 = (void *) 0x2

// dispatching of both doesn't result in press or release events
$1532 = "dispatch"


$1533 = "dispatch"


$1534 = "leaving"

// Huh, another leaving, obviously no events in any queue
$1535 = "leaving"

// Once more dispatching with nothing of interest for us
$1536 = (void *) 0x1


$1537 = "dispatch"


$1538 = "leaving"

// here comes the queue containing the release event
// of the first click
$1539 = (void *) 0x1

// the dispatch results in the release event and the button
// triggers the doStuff() function.
$1540 = "dispatch"
"QPushButton(0x809d128) release"
false
0

// -----
// Now the qSleep() runs for 5 secs. I clicked 3 times.
// There is no way Qt can process the individual presses
//and releases. The window system buffers them until Qt has time.
// -----
// qSleep() finished, the signal for UNBLOCKING is emitted
// and the connected signal is enqueued in the posted events queue.
// -----

// leave the dispatching function
$1541 = "leaving"

// -----
// Now Qt receives the three remaining mouse clicks at once
// and puts ALL of them in a SINGLE spontaneous queue.

// enters the dispatching function, two queues contain events
$1542 = (void *) 0x2

// first queue dispatched, the one with the posted event
// unblocking occurs
$1543 = "dispatch"
"MainWindow(0xbfffe180) queued"
unblock()

// second queue dispatched,
// the one with the THREE press/release pairs !!!
$1544 = "dispatch"

// first press/release pair triggers button clicked signal
// and that in turn the signal blocking
"QPushButton(0x809d128) press"
"QPushButton(0x809d128) release"
false
1

// -----
// now the signals are blocked and qSleep() runs
// qSleep() finished and the signal for UNBLOCKING is emitted
// and the connected signal enqueued in the posted events queue.
// follwing two press/release pairs don't trigger the
// clicked signal (due to the blocking)
// -----

"QPushButton(0x809d128) press"
"QPushButton(0x809d128) release"
"QPushButton(0x809d128) press"
"QPushButton(0x809d128) release"

// leaving dispatch function
$1545 = "leaving"

// entering again the dispatch function with two queues
// containing events
$1546 = (void *) 0x2

// the unblocking
$1547 = "dispatch"
"MainWindow(0xbfffe180) queued"
unblock()

// and something unknown
$1548 = "dispatch"


$1549 = "leaving"

因此,很明显为什么发布的解锁会干扰点击。 没有机会阻止所有点击,因为 qt 在其他事件之前处理已发布的事件(解锁)。只有缓冲点击的整体处理“似乎”有效。

如果将阻塞信号与耗时处理结合使用,请牢记这一点。

这也解释了为什么我的“hack”(见下文)使用 QMetaObject::invokeMethod 来调用 SIGNAL 有效。 它会导致重定向并需要两个已发布的事件。第一个用于 SIGNAL(否则会立即使用 emit() 调用),第二个用于 SLOT。只有这样才会发生解锁。到那时,在按钮仍处于静音状态时已发送额外的点击:

1. click // dispatched, blocking

qSleep() // meanwhile clicking 3 times
// followed by enqueuing the SIGNAL
// followed by enqueuing the 3 clicks in a single queue

unblocking SIGNAL // dispatched, unblocks not yet

2.,3., and 4. click // dispatched, but button still blocked

unblocking SLOT // dispatched, finally unblocks

在我下面的“解决方案”中,使用非阻塞本地事件循环而不是阻塞 qSleep(),三次点击将被立即处理(而不是unblock 入队后)并且不会发出任何信号。


解决方案同时保持 qSleep():

我通过使用 QMetaObject::invokeMethod() 调用 SIGNAL 解决了这个问题:

QMetaObject::invokeMethod(this, "delayed_unblock", Qt::QueuedConnection);

代替 emit(delayed_unblock());


解决方案使用本地事件循环:

void MainWindow::doStuff()
{

qDebug() << btn->signalsBlocked();
qDebug() << num++;
btn->blockSignals(true);

QTimer t;
t.setSingleShot(true);
t.setInterval(5000);
QEventLoop loop;
connect(&t, SIGNAL(timeout()), &loop, SLOT(quit()));
t.start();
loop.exec(); // lets event processing happen nothing blocked (no mopuseclicks stuck in the windows system !?)

//QMetaObject::invokeMethod(this, "delayed_unblock", Qt::QueuedConnection);
emit(delayed_unblock());

}

解决方案 在 qSleep() 之后立即使用 processEvents

QApplication::processEvents(); 似乎立即接收和发送 Windows 系统事件。这也解决了这个问题。


由于历史原因留下以下行; )

因为 Qt 5.6 的文档告诉我们“被阻塞时发出的信号不会被缓冲”。考虑一下.. 什么都没有发出,因为 qSleep() 阻止了应用程序。完全地。因此,在 qSleep() 完成之前,Qt 根本无法控制单击的鼠标按钮(仍然停留在 Windows 或 X11 中)。而且应该是windows系统对点击进行了缓冲的缘故。在计时器结束后,第一次点击将在其他所有操作(包括解锁)之后进行处理。对于剩余的点击,信号再次被阻止。 (@thuga 解释得很好)。

关于c++ - Qt blockSignals 没有阻止第一次额外点击,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/37288084/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com