背景：
学习qt表格控制，写博文记录：
【QT表格-1】QStandardItem的堆内存释放需要单独delete，还是随QStandardItemModel的remove或clear自动销毁？
【QT表格-2】QTableWidget单元格结束编辑操作endEditting_qtablewidget 单元格编辑事件
【QT表格-3】QTableWidget导入/导出excel通用代码，不需要安装office，不依赖任何多余环境，甚至不依赖编程语言
【QT表格-4】由QTableView/QTableWidget显示进度条和按钮，理解qt代理delegate用法
【QT表格-6】QTableWidget的currentCellChanged实现中途撤销
一个主子表结构，当切换主表行时， 子表对应更新显示数据。主子表都可以编辑并保存。
当子表编辑后未保存时，如果切换主表行，应提示保存，用户可以选择“是”、“否”、“取消”。其实“是”和“否”好实现，因为都是保持顺序执行，只不过选择是否执行保存而已。但“取消”就不一样了，需要停止下面的操作。
这种情况比较多见，比如某个文本编辑器，如果编辑的内容，关闭时就应该有这样的询问。并根据用户选择进行相应操作。
按说用过vs的winform的同行应该知道，这个并不难。现在看来是因为vs提供了相当丰富的消息事件响应机制。比如关闭窗口会有一个类似CloseQuery这样的消息，只要对应写它的事件就好了。但是qt当中，思路会有很大区别。
问题：
实际上我尝试了很多方法已经就差cancel动作了。在QTableWidget::currentCellChanged槽当中判断，如果用户放弃的操作，我会重新把焦点放到previous位置，
this->setCurrentCell(previousRow, previousColumn);
这样看起来就是“回滚”了用户操作。但实际上效果是，焦点确实回去了，所有属性也回去了，比方说，currentRow或者currentItem之类，都没问题，但单元格的背景色没回去，也就是看起来还是选择了下一个位置。
这不傻了么？怎么试都不行，我猜想qt肯定是在currentCellChanged之后还干了什么事，而这个信号没有提供返回值和指针参数或者引用参数，等于没法控制。所以开始研究。
开胃菜：
以上述“窗口关闭前询问”为例，其实qt有个closeEvent函数，重写它就行了。它有个event指针参数，通过它是否accept就能控制是否继续。比如：
void MainWindow::closeEvent(QCloseEvent *event)
{
const QString sTitle = "程序退出";
const QString sMessage = "此操作会退出系统\n"
"当前未保存的数据将丢失\n"
"要继续吗？";
if (QMessageBox::question(this, sTitle, sMessage, QMessageBox::Yes|QMessageBox::Cancel,QMessageBox::Cancel)
== QMessageBox::Yes)
{
event->accept();
}
else
{
event->ignore();
}
}
就像上图这样，挺简单的。
同理，很多需要控制是否继续的做法，都类似。
回到正题，最初我的需求怎么办？我需要切换主表行时来个询问，并决定是否继续。
分析：
如果直接套用closeEvent的思路，是想不通的。因为那是继承重写的做法。而表格是某个界面中的子对象，询问的操作需要在表格外实现，怎么重写？
像这种常见的界面互动，要么直接调用函数，要么信号槽。不想随便触动函数指针的概念，我感觉应该先深入了解qt的方式。
直接调用：业务是需要表格内部，根据外界的用户选择，来决定内部的流程是否继续。理论上是表格内部调用外部。但制作表格类的时候，是不知道外界是否需要询问，或者如何询问的。貌似无解。
信号槽：界面线程的互动属于directConnection，效果很顺序执行一样。这里涉及到信号槽的一些基础概念。主要是connect函数最后一个连接参数的应用。以手册为准。
但是信号槽怎么互动？发出去再传回来？难道需要收发两次？显然不是好办法，毕竟繁琐，主要是用起来感觉还不是随大流的风格。
过程：
过程艰辛，最终我是下载的qt源码才知道怎么回事的。这里只说关键步骤。
对于我的需求，主要用到QTableWidget::currentCellChanged信号，目的是能根据用户选择决定是否继续，还是取消。经过研究qt源码，QTableWidget.cpp有这样一段：
void QTableWidgetPrivate::_q_emitCurrentItemChanged(const QModelIndex ¤t,
const QModelIndex &previous)
{
Q_Q(QTableWidget);
QTableWidgetItem *currentItem = tableModel()->item(current);
QTableWidgetItem *previousItem = tableModel()->item(previous);
if (currentItem || previousItem)
emit q->currentItemChanged(currentItem, previousItem);
emit q->currentCellChanged(current.row(), current.column(), previous.row(), previous.column());
}这样看着后面没干什么事，只是看到currentItemChanged比currentCellChanged要靠前触发，而且有先决条件。接着看，_q_emitCurrentItemChanged这个信号是怎么来的。
void QTableWidgetPrivate::setup()
{
...
// selection signals
QObject::connect(q->selectionModel(), SIGNAL(currentChanged(QModelIndex,QModelIndex)),
q, SLOT(_q_emitCurrentItemChanged(QModelIndex,QModelIndex)));
QObject::connect(q->selectionModel(), SIGNAL(selectionChanged(QItemSelection,QItemSelection)),
q, SIGNAL(itemSelectionChanged()));
...
}那个q->selectionModel()跟踪一下就知道，它是QAbstractItemView::selectionModel()，是个QItemSelectionModel。主要看它的currentChanged和selectionChanged这俩信号的途径。
在qitemselectionmodel.cpp中搜索currentChanged就看见原因了，确实是currentChanged发送以后，会有更新界面的代码，最后再发送selectionChanged。代码太多就不贴了。
但是还有QTableWidget::setCurrentCell，QAbstractItemView::setCurrentIndex，最终都是执行的QItemSelectionModel::setCurrentIndex。而在这里面，selectionChanged是先于currentChanged的。
当执行setCurrent时，CellChanged是最后执行的。（这点要稍后考虑，先看用户主动操作的情况。后面在“疑点”部分逐一说明。）
当用户操作界面时，selectionChanged才是最后执行的，如果要回滚界面，也要在这里。但有个很恶心的事情。看这个：
QObject::connect(q->selectionModel(), SIGNAL(selectionChanged(QItemSelection,QItemSelection)), q, SIGNAL(itemSelectionChanged()));
连接时丢了两个很重要的参数，不知道qt为什么这样。（其实，qt也确实有类似的解决方案，我自己也不经意间用过，下文“疑点”会提到。）后来我想，也许提供一个没有参数的槽，更方便以后显式调用，因为不用刻意传参了，否则，如果在不容易获得入参值，而又想调用功能的情况下，就不方便了。
原因找到，解决就容易了。
方法：
我的QTableWidget自己包装了一个类，
先定义一个发往外界的查询信号：void sigRowChangeQuery(QEvent *event);。内含event指针，用于判断用户操作，很符合qt风格。这里注意，因为是界面交互，都在ui线程，所以默认是direct连接方式，所以可以接收到event的更改。
当然还有另外一个信号：void sigRowChanged(int iRow);，见名知意，通知外界行选发生。
写了槽on_currentCellChanged用于处理行选。其中：
if (m_bIsCurrentCellChangeProtected || currentRow < 0 || currentColumn < 0)
{
return;
}
if (currentRow != previousRow)
{
QEvent event(QEvent::None);
event.accept();//这里需要思考，见后续说明。
emit sigRowChangeQuery(&event);
if (!event.isAccepted())//If the slot was canceled by the user.
{
m_iRow_Rollback = previousRow;
m_iCol_Rollback = previousColumn;
m_bIsSelectionRollback = true;
return;
}
emit sigRowChanged(currentRow);
}
用两个变量记住要回滚的位置。再写槽on_itemSelectionChanged处理界面回滚：
if (m_bIsCurrentCellChangeProtected)
{
return;
}
if (m_bIsSelectionRollback)
{
m_bIsSelectionRollback = false;
m_bIsCurrentCellChangeProtected = true;
this->blockSignals(true);
QTableWidget::setCurrentCell(m_iRow_Rollback, m_iCol_Rollback);
m_bIsCurrentCellChangeProtected = false;
this->blockSignals(false);
}
这样就行了。
外面处理用户操作时，写槽onGridMain_RowChangeQuery(QEvent *event)，根据判断再设置event的accept标志，这样的用法就顺畅多了。是不是跟closeEvent用法一样？就是要这种效果。
所以这样的做法可以延伸的其它类似的场景。
说明：上面构造QEvent那里，是否思考一下？理论上，像这种通过event.isAccept来决定是否继续的程序，默认是继续执行的。亦即：event.accept应初始化为true。例如：窗体的closeEvent，如果不处理它，窗体就应该默认关闭，想在关闭前询问时，重写closeEvent再通过event.accept/ignore来控制是否继续。所以妥善期间，应初始化accept=true。但是我测试过，不初始化也没问题，因此研究event源码，在qcoreevent.cpp中看到：
QEvent::QEvent(Type type) : d(0), t(type), posted(false), spont(false), m_accept(true)
{
Q_TRACE(QEvent_ctor, this, t);
}
这就对了，初始化列表中很明显看到m_accept(true)，就是m_accept = true的意思。
顺便看看相关源码，非常明确，比看帮助有效。
inline void setAccepted(bool accepted) { m_accept = accepted; }
inline bool isAccepted() const { return m_accept; }
inline void accept() { m_accept = true; }
inline void ignore() { m_accept = false; }
疑点1：
上文提到：
当执行setCurrent时（比如setCurrentCell，setCurrentItem等），CellChanged是最后执行的。因为最终都是调用的QItemSelectionModel::setCurrentIndex：
void QItemSelectionModel::setCurrentIndex(const QModelIndex &index, QItemSelectionModel::SelectionFlags command)
{
Q_D(QItemSelectionModel);
if (!d->model) {
qWarning("QItemSelectionModel: Setting the current index when no model has been set will result in a no-op.");
return;
}
if (index == d->currentIndex) {
if (command != NoUpdate)
select(index, command); // select item
return;
}
QPersistentModelIndex previous = d->currentIndex;
d->currentIndex = index; // set current before emitting selection changed below
if (command != NoUpdate)
select(d->currentIndex, command); // select item
emit currentChanged(d->currentIndex, previous);
if (d->currentIndex.row() != previous.row() ||
d->currentIndex.parent() != previous.parent())
emit currentRowChanged(d->currentIndex, previous);
if (d->currentIndex.column() != previous.column() ||
d->currentIndex.parent() != previous.parent())
emit currentColumnChanged(d->currentIndex, previous);
}所以，使用代码设置当前位置时，情况跟用户点击是不一样的。qt会先设置selection，再触发cellchanged。
当然setCurrentCell和setCurrentItem函数，还提供了一个重载，带一个参数QItemSelectionModel::SelectionFlags，用于指定要不要更改selection。所以，在必要的地方setCurrentCell时，指定不更改selection，之后再显式调用一下on_itemSelectionChanged，相当于强制让selection设置在cellchanged之后。而调用无参的on_itemSelectionChanged确实更方便，这就又扣题上文了。
问题1：乍一听是不是很有道理？其实还有个坑，setCurrent的时候如果指定了不更改selection，后期更新？不存在的！因为表格支持的模式很多，比如多选，一旦你自己控制，就要考虑十分周全，所以那个参数还是不要用，宁可之后必要的时候，在set一次selection。只不过界面上看起来是，选择状态先改过去了，等一撤销又回来了。视觉上不爽，以及效率不最高。但权衡利弊，值得。
问题2：on_itemSelectionChanged其实还是靠调用setCurrentCell来实现的selection状态变化。我没有用QTableView::setSelection函数。因为看过源码，内部的选择状态，是在一个叫selectionChanged的槽函数（“疑点2”中提到）内部实现的，而这个槽根本上还是靠QItemSelectionModel::selectionChanged这个信号触发的。而QTableView::setSelection是自己硬在界面层面计算rect实现的。这个就与内部联动脱节了，实在是不好操作，我还要考虑SelectionBehavior（选择模式：行，列，等）。所以不如让qt自带的功能实现更方便。
综合上述两点，你还觉得有自己控制selection的必要吗？反正我是认怂了，还是尽量用qt自带的功能实现。
注意：因为on_itemSelectionChanged里面调用了setCurrentCell，如果不加标记还会触发currentCellchanged，那就死循环了，所以要考虑周全。
疑点2：
上文提到：
QObject::connect(q->selectionModel(), SIGNAL(selectionChanged(QItemSelection,QItemSelection)), q, SIGNAL(itemSelectionChanged()));
连接时丢了两个很重要的参数。且不提“疑点1”提到的方便调用问题，但其实qt有类似的解决方案。注意看，这个叫大壮的男人，点开了qt手册，他竟然发现了这么个玩意：
QTableWidget::selectionChanged(const QItemSelection &selected, const QItemSelection &deselected)
但其实以前也重写过这个虚函数，这次的问题，因为一开始没想到selection，所以没往这看。
跟踪一下就知道，这个虚函数继承自QAbstractItemView>QTableview。而它的触发，看源码：
void QAbstractItemView::setSelectionModel(QItemSelectionModel *selectionModel)
{
...
if (d->selectionModel) {
connect(d->selectionModel, SIGNAL(selectionChanged(QItemSelection,QItemSelection)),
this, SLOT(selectionChanged(QItemSelection,QItemSelection)));
connect(d->selectionModel, SIGNAL(currentChanged(QModelIndex,QModelIndex)),
this, SLOT(currentChanged(QModelIndex,QModelIndex)));
selectionChanged(d->selectionModel->selection(), oldSelection);
currentChanged(d->selectionModel->currentIndex(), oldCurrentIndex);
}
}还是从d->selectionModel的selectionChanged信号过来的，而d->selectionModel是QItemSelectionModel，所以，来源还是QItemSelectionModel::selectionChanged这个信号。这就和上文的方法对上了。
但是，利用selectionChanged这个虚函数，会否能做个更“优”解呢？我想目前是没有必要了。先这样，想到再补充。
心得：
个人感觉，qt源码中关于cellchanged和selection的顺序，应该保持一致就好了。
本文完。
2751
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
