Как создать искусственные узлы в QAbstractItemModel для QTreeView - PullRequest
2 голосов
/ 01 февраля 2010

мой вопрос касается Qt и его QAbstractItemModel .

У меня есть карта строк и двойников (std::map<stringclass, double>), которую я хотел бы представить в виджете Qt. Хотя для этого я мог бы использовать QTableView , я хотел бы использовать тот факт, что ключи карты имеют форму "abc.def.ghi", где может быть несколько строк, которые могут начинаться с "abc.def" и даже больше, которые начинаются с "abc".

Итак, я хотел бы настроить древовидную модель данных для представления элементов в QTreeView , например

(-) abc
    |--(-)def      
          |--ghi    3.1415
          |--jkl    42.0815
    |--(+)pqr
    |--(+)xyz

Ключи моего std::map - это листья дерева, где все другие узлы будут временными и вспомогательными конструкциями для поддержки свертывания для удобства пользователя.

К сожалению, методы rowCount, index, columnCount и data имеют const-модификаторы, поэтому я не могу просто установить вспомогательную структуру данных для заголовков внутри моего QAbstractItemModel производного и измените эту структуру данных там.

Что было бы лучшим для этого? Должен ли я установить другой слой класса между моим std::map и QAbstractItemModel или есть более разумный способ сделать это?


Редактировать 1: std::map может измениться, пока QTreeView отображается и используется, поэтому вспомогательные узлы могут быть выброшены и восстановлены. Я предполагаю, что лучший способ справиться с этим - это реструктурировать QAbstractItemModel - или я должен просто выбросить эту модель и назначить вновь созданную модель для QTreeView ? В этом случае я мог бы настроить все узлы в конструкторе, не беспокоясь о постоянстве методов, я думаю.

Ответы [ 2 ]

4 голосов
/ 01 февраля 2010

Я бы проанализировал карту и создал на ее основе древовидную структуру данных. Обязательно синхронизируйте модель при смене карты. Если этот шаг синхронизации становится слишком сложным, вы можете с самого начала сохранить данные в древовидной структуре и при необходимости преобразовать их в карту.

Анализ карты на лету в функциях модели кажется мне плохой идеей, вы бы хотели, чтобы эти функции работали как можно быстрее.

0 голосов
/ 01 февраля 2010

Я не понимаю, как const-модификаторы могли бы стать проблемой.

Какие члены вашего QAbstractItemModel производного вы хотите изменить при вызове методов rowCount, index, columnCount и data? Вы можете очень хорошо хранить ссылку на свою карту и вычислять все на ней. Не нужно изменять саму карту для извлечения необходимой информации (насколько я могу судить!).

РЕДАКТИРОВАТЬ после РЕДАКТИРОВАНИЯ1 и комментариев :
Если ваша карта должна быть изменена, используйте ее в качестве базовой структуры в своем собственном классе. Если вы не можете сохранить ссылку на карту, поскольку срок жизни модели может превышать срок действия карты, используйте умные указатели, чтобы этого не произошло.

...