Qt accept（）应该只在插槽的末尾使用吗？

我看到

accept（）

有点类似于

return

，所以我一直把它放在插槽的末尾，之后就没有代码了。也就是说，

accept（）

“完成”对话框的执行

尽管如此，我还是发现需要关闭一个对话框，然后从第一个对话框的插槽中打开一个新对话框。因此，我的想法是将

accept（）

移动到插槽的开头，并初始化插槽后面的第二个对话框。如下所示：

void FirstDialog:slotFirstDialog()
{
  accept();
  // Setup second dialog arguments
  // ...
  SecondDialog *sd = new SecondDialog();
  sd->exec();
}

使用

accept（）

有效吗？这是一种好的做法吗？

使用对话框代码调用。以下是

QDialog:：done

的外观：

void QDialog::done(int r)
{
    Q_D(QDialog);
    setResult(r);
    hide();
    d->close_helper(QWidgetPrivate::CloseNoEvent);
    d->resetModalitySetByOpen();
    emit finished(r);
    if (r == Accepted)
        emit accepted();
    else if (r == Rejected)
        emit rejected();
}

其中，根据

隐藏“模式”对话框并将结果代码设置为“已接受”

---

考虑到这一点，我认为这不是一个好的实践问题，而是应用程序逻辑需要什么的问题。

我会避免它。调用

accept（）

可以触发延迟删除

FirstDialog

（例如，如果设置了

Qt:：WA_DeleteOnClose

标志）1；在这种情况下，它将在嵌套事件循环（

sd->exec（）

）调度的第一个事件中被删除，这将导致在已删除实例的方法中继续执行代码。这只是我头脑中的一个示例问题，我相信还可以找到其他问题

我可能会在另一个调用

exec（）

之前隐藏该对话框，并在嵌套事件循环结束后调用

accept（）

void FirstDialog:slotFirstDialog()
{
    // Setup second dialog arguments
    // ...
    SecondDialog *sd = new SecondDialog();
    hide();
    sd->exec();
    accept();
    // NB are we leaking sd? 
}

---

顺便说一下：

SecondDialog *sd = new SecondDialog();
sd->exec();

这里，您在堆上分配一个没有父对象的对话框，因此要么设置

Qt:：WA_DeleteOnClose

，要么在其代码中显式调用

this->deleteLater（）

，要么泄漏对话框实例

---

注:

它被明确地指出

与

QWidget:：close（）

一样，如果设置了

Qt:：WA_DeleteOnClose

标志，则

done（）

将删除对话框

---

我将“accept（）”移到函数的末尾，并在开头添加了一个“hide（）”。这就是你的意思吗？是的，就是这个意思。还可以查看第二个对话框的生命周期：谁负责在您的代码中删除它？谢谢，这似乎有效。你能编辑你的答案，用我的原始代码添加一段代码摘录，但用hide（）进行“修复”，这样答案就更完整了吗？你是对的，我在泄漏内存。所以应该是“SecondDialog*sd=newseconddialog（this）；”。此外，我会将“hide（）；”放在函数的开头，以便更“忠实于”函数，而“第二个对话框初始化”是包装的行为。我的应用程序逻辑要求一个对话框打开另一个对话框。我不清楚从你的答案中摘录的代码是否正确not@Alechan，正如我已经提到的：我认为这不是一个良好实践的问题，而是应用程序逻辑需要什么的问题。因此，我向您展示了

done

的功能，以便能够根据您的具体应用程序决定是否需要在插槽的开始或结束时执行此操作。