![]() |
Здравствуйте, гость ( Вход | Регистрация )
![]() |
Rocky |
![]()
Сообщение
#1
|
Старейший участник ![]() ![]() ![]() ![]() Группа: Участник Сообщений: 530 Регистрация: 22.12.2008 Из: Санкт-Петербург Пользователь №: 463 Спасибо сказали: 22 раз(а) Репутация: ![]() ![]() ![]() |
Вроде бы внимательно изучил документацию, примеры simple и edit tree model. Начал сам делать и совсем запутался... Помогите распутаться плиз... Хочу сделать 3-х уровневую модель дерева. В примерах есть класс TreeItem который содержит указатель на родителя и список чайлдов. Но этот родитель и элементы списка сами являются TreeItem. С этим вроде бы ясно... А как развернуть эту структуру? Чтобы данные как бы отделить друг от друга?
Например превратить ее в 4 класса: 1. Класс самой модели. 2. Класс с данными верхенго уровня (содержит список данных и список чайлдов 3) 3. Класс с данными среднего уровня (содержит список данных и список чайлдов 4 и указатель на парента 2) 4. Класс с данными нижнего уровня (содержит список данных и указатель на парента 3) А как при таком раскладе написать тела виртуальных функций QAbstractItemModel (index и parent и rowCount)? 3-й день сижу и ниче не получается ( Или этот подход неверен? Сама задача такая. Есть список имен. Каждому элементу из этого списка соответсвует список других имен. Каждому элементу из последнего списка соответсвует набор данных. Как это все представить для модели? (( Спасибо если кто-нибудь что-нибудь подскажет... Сообщение отредактировал Rocky - 14.12.2010, 11:47 |
|
|
![]() |
kuzulis |
![]()
Сообщение
#2
|
Активный участник ![]() ![]() ![]() Группа: Участник Сообщений: 393 Регистрация: 29.6.2009 Пользователь №: 862 Спасибо сказали: 36 раз(а) Репутация: ![]() ![]() ![]() |
Цитата Т.е. что, получается что не нужно наследоваться от QAbstractItemModel а тупо заполнять дерево вручную? Нужно наследоваться. Просто суть такова, что источником данных для модели выступает класс TreeItem. Т.е. каждый TreeItem содержит список столбцов(собственно - данных), а также список строк(список указателей на дочерние итемы). т.е. источник данных типа TreeItem специально имеет древовидную структуру для того чтобы легко его можно было адаптировать к QAbstractItemModel-ли. Так вот, переопределяя в модели виртуальные методы, мы тем самым, можем для любого итема источника данных показать любые его данные какие хотим. К примеру, итем TreeItem имеет список данных из 3-х столбцов, но мы хотим показать только два из них, поэтому, переопределяя виртуальный метод в модели, мы можем подсовывать в него нужные нам столбцы TreeItem . Вместо списка данных TreeItem типа QList<QVariant>, можно испоотзовать любые структуры данных. QList<QVariant> в примере (ИМХО) приведен чисто чтобы показать как оно работает, т.е. общий случай. Тем более, что в QList<QVariant> можно впихнуть любые данные, поэтому такое решение универсально. Цитата Так а если нужно обрабатывать нажатие мыши то как тогда с таким подходом? Нажатие мыши обрабатываются в TreeView, при этом, ты получаешь готовый текущий QModelIndex, и можеш, зная его, изменить в нем данные с помощью методов модели типа setData() и т.п. т.е. в данном случае, подразумеваем, что данные в источнике ты меняешь сверху вниз, т.е: TreeView->Model->DataSource. А вот если у тебя данные в TreeItem кто-то меняет извне (например какой-то алгоритм), то тут нужно придумать какой-то механизм чтобы уведомить модель о том, что данные в данном итеме TreeItem изменились. т.е. этим механизмом будет являться твоё собственное API. Как-то так... В общем, весь этот подход MVC какой-то не особо универсальный. ИМХО. ЗЫ: Я сам долго анализировал и втыкал что есть что. Вот, довтыкался ![]() |
|
|
![]() ![]() ![]() |
![]() |
Текстовая версия | Сейчас: 18.2.2025, 4:02 |