Qt 表格升级攻略：复用已有编辑器，减少重复开发

**Qt 表格升级时，已有自定义单元格编辑器的迁移成本，容易被功能对比表掩盖。**项目可能已经实现了特殊字段的绘制、鼠标交互和数据提交；引入新表格组件后，如果重新实现这些逻辑，开发和回归验证的投入也会随之增加。

例如，桌面软件的数据表需要增加分组和汇总，但部分列已有定制编辑器。选型时就要同时考虑两件事：新组件能承担哪些通用交互，原来的编辑逻辑又能保留多少。

Developer Machines 的 QtItemDelegate 官方示例提供了一个具体切口：将 Qt 的星级评分 delegate 接入 QtitanDataGrid，展示已有编辑逻辑的复用途径。

一、Qt 原生表格的扩展能力，需要配套实现

QTableView 通过模型提供数据，通过 delegate 完成单元格显示与编辑。QStyledItemDelegate 已支持常见数据类型，也允许开发者重写绘制、编辑器创建和数据读写方法。

但基础表格与完整的数据操作界面之间，仍有集成工作。以表内分组和分组汇总为例，它们并非 QTableView 配置一个属性就能得到的完整交互，通常需要进一步组织模型、视图和配套界面。

这类改造容易出现两头投入：一边补充通用功能，另一边重新适配特殊字段。对于已经验收过的编辑逻辑，重写还意味着重新核查原有操作习惯和数据处理结果。因此，复用是否可行，应在选型阶段尽早确认。

QtitanDataGrid 将分组、汇总等机制集成到组件中，同时提供 delegate 适配编辑器。对于已经积累定制代码的团队，这意味着评估新表格能力时，可以先验证已有编辑逻辑的接入，而不必直接按重写估算。

二、官方案例：把星级评分编辑器接入新表格

官方示例使用 Title、Genre、Artist、Rating 四列歌曲数据。Rating 由 StarRating 表示评分，StarDelegate 负责显示与编辑，StarEditor 提供实际交互。这是功能演示，并非客户项目案例。

接入的关键代码位于官方 window.cpp。以下保留相关配置，省略窗口与菜单初始化，假定 view 已绑定示例模型，并处于 Qtitan 命名空间作用域：

复制代码

Qtitan::GridTableColumn* column =
    (Qtitan::GridTableColumn*)view->getColumn(3);

column->setEditorType(GridEditor::DelegateAdapter);

GridDelegateAdapterEditorRepository* adapter =
    static_cast<GridDelegateAdapterEditorRepository*>(
        column->editorRepository());

adapter->setDelegate(new StarDelegate);
adapter->setDefaultValue(
    QVariant::fromValue(StarRating(5)), Qt::EditRole);

这里先为第四列选择 DelegateAdapter，再安装 StarDelegate；最后一行设置编辑角色的默认值。接入点位于列的编辑器配置中，评分绘制与交互仍由 delegate 承担。

因此，值得关注的是"接入已有实现"这条路径，而不能把几行配置理解为整个表格升级只需几行代码。

三、复用是否成立，要看完整的数据读写链路

只显示星形图案，还不足以证明编辑器能够复用。官方 StarDelegate 的 setEditorData() 与 setModelData() 给出了读写衔接：

复制代码

void StarDelegate::setEditorData(
    QWidget* editor, const QModelIndex& index) const
{
    if (index.data().canConvert<StarRating>()) {
        StarRating starRating = qvariant_cast<StarRating>(index.data());
        StarEditor* starEditor = qobject_cast<StarEditor*>(editor);
        starEditor->setStarRating(starRating);
    } else {
        QStyledItemDelegate::setEditorData(editor, index);
    }
}

void StarDelegate::setModelData(
    QWidget* editor, QAbstractItemModel* model,
    const QModelIndex& index) const
{
    if (index.data().canConvert<StarRating>()) {
        StarEditor* starEditor = qobject_cast<StarEditor*>(editor);
        model->setData(index, QVariant::fromValue(starEditor->starRating()));
    } else {
        QStyledItemDelegate::setModelData(editor, model, index);
    }
}

前者将模型中的评分交给编辑器，后者把修改结果写回模型。两处均保留了普通类型的默认处理。注意这里使用 index.data()，读取默认的 DisplayRole；官方模型同时为 DisplayRole 和 EditRole 返回 StarRating，使类型保持匹配。

这一点也解释了迁移中的常见衔接问题：如果新模型只返回整数，原来的类型判断就可能无法进入评分编辑分支。仅复制编辑器类，并不能补齐数据契约；模型返回什么、编辑器接受什么、提交后保存什么，需要逐项对应。

编辑结束时，delegate 还需要通知视图提交数据并关闭编辑器：

复制代码

void StarDelegate::commitAndCloseEditor()
{
    StarEditor* editor = qobject_cast<StarEditor*>(sender());
    emit commitData(editor);
    emit closeEditor(editor);
}

在示例模型的 setData() 中，评分被转换为内部数值保存，随后发送 dataChanged。适配器没有替项目定义业务数据结构，也没有替代模型的数据更新职责。

四、从一个已有字段开始评估复用收益

实际验证时，可先选择一个已有 delegate，检查显示与编辑所需的数据类型、修改提交和单元格刷新，再加入项目需要的排序或分组，核对操作后的记录与写回对象是否一致。

例如，修改一条评分后重新进入该单元格，检查新值能否正确回显；再改变排序，确认修改没有落到另一条记录。对于键盘操作较多的项目，还应核对进入编辑、结束编辑和焦点切换。验证重点应覆盖一次真实修改过程，而不是只比较两张界面截图。

如果 delegate 依赖旧视图对象、固定行号或特殊事件处理，还需要单独核查；官方示例不能直接证明所有项目都能无改动迁移。本文代码为官方片段整理，依赖完整示例类，接口以所用版本为准。

**QtitanDataGrid 在这一场景下的优势，是在提供通用表格交互的同时，为已有 Qt delegate 保留接入路径。**团队可以把编辑器复用纳入选型验证，减少重新实现特殊字段的工作，将开发投入集中到新增需求与必要的适配上。

这里是慧都科技，如需了解更多QtitanDataGrid的信息，欢迎沟通交流，评论私信~