Здравствуйте, гость ( Вход | Регистрация )
PAFOS | Дата 5.8.2011, 13:53 |
Для начала я бы сделал одну модель и два представления. Как ни крути делать две модели для одних и тех же данных неправильно. Модель будет иметь иерархическую структуру Проект1 Задача 1 Задача 2 Проект2 Задача 3 Без проекта Задача 4 Реализация такой модели - дело практики. Идем далее...
заменяем на
Такая структура существенно сократит реализацию модели Однако надо быть внимательным с указателями и т.п. И напоследок: Если посмотреть внимательно на класс QAbstractItemView, то можно найти классный метод setRootIndex( QModelIndex ) Для древовидного представления setRootIndex() должен быть QModelIndex::invalid() (т.е. корень модели) А для списка - выделенный в древовидном представлении QModelIndex типа "Проект". |
|
explorer85 | Дата 4.8.2011, 12:14 |
Спасибо за ответы, но просто для всего что вы описали в mvc qt есть стандартные вещи: dataChanged, Begin..EndInsertRows итд. Просто оно как бы все уже есть но вот правильно ли я этим пользуюсь в своей ситуации я не знаю. Вообще по жизни стараюсь придерживаться правила не изобретать велосипеды и если есть что то готовое пользоваться этим. Но за соблюдение этого правила, приходиться расплачиваться необходимостью подстраиваться под чужие уже написанные решения. |
|
Алексей1153 | Дата 4.8.2011, 11:30 |
Цитата Хотя интересно как там сделано)) да очень просто всё сделано (кхм, если работу с АПИшными Tree View и List View можно вообще назвать простыми. Это ад! Но ад программистский, а не логический) - я делал такую вещь для одной из программ (не на Qt). Главное: отделить GUI от логики и от данных. Окно лишь показывает текущее состояние данных, а также позволяет ввести новые данные (для создания нового элемента либо для замены содержимого существующего). После изменения данных окно должно перерисоваться, чтобы показать текущее содержимое данных. Под перерисовкой понимается не принудительная перерисовка всего, а, возможно, перерисовка только необходимой части окна для отображения изменений. Но само окно понятия не имеет, что поменялось! Даже несмотря на то, что именно окно помогло ввести данные. Хранилищем окно не управляет - оно передало введённую информацию и забыло. Перерисовалось. Типа - "я сделало всё, что могло, сотрите, что теперь в данных". Оба окна не зависят друг от друга. Они зависят от данных. А то, как сортировать, это уже просто - выводят содержимое данных в том виде, в каком пользователь попросил. Цитата зачем таймер если есть сигналы и слоты если получится - пожалуйста. но я бы не стал городить сложную систему оповещений там, где она не нужна. По опыту знаю, что в данном случае проверка по таймеру - достаточно. И сильно упрощает. Если непонятно рассказываю, могу схемку накидать )) Цитата какое я щас вижу решение? делать еще одну связку модель + представление + делегат, передавать модели указатель на Storage с данными .........ну итд. То есть получается некислое дублирование кода, рост сложности кода проекта ну итд со всеми вытекающими.... И таймер вновь спешит на помощь Сменишь счётчик вхолостую и всё готово. Кстати говоря, таймер то таймером, он обновит раз в секунду, что нормально для обновления вида других окон (не в фокусе), но не очень то для текущего окна (сказали сортировать - а оно отреагировало через секунду...) . Тут делаем так: то, что вызывается в обработчике таймера для обновления окон, надо иметь возможность вызвать в любой момент. Увеличили счётчик вхолостую, вызвали процедуру. Дальше всё по накатанной |
|
explorer85 | Дата 4.8.2011, 11:23 |
по сути у тебя аналог окна виндового Explorer (дерево папок слева, содержимое папки - справа) только не для файловой системы, а для дерева проектов Да попал в точку. Щас потыркал проводник та же концепция. Ну только разве что эти два вида у меня доступны не одновременно. А так тоже самое слева проекты, справа задачи)) и если обратил внимание то и модель фильтрации и сортировки для каждого вида тоже своя. Ведь в проводнике если справа в списке сортировать элементы то влевом они остаются в том порядке каком и были. ну это так философия. Хотя интересно как там сделано)) Ты упоминаешь, что передаёшь указатель на экземпляр своего класса. При изменениях меняется счётчик. Уведомлений, конечно же, никаких не произойдёт, их надо инициировать. Я бы сделал проверку по таймеру (скажем, раз в секунду) счётчика, и при его изменении обновлял бы представление, которое не в фокусе (тут спорный вопрос - наверное, вместе со счётчиком полезно запоминать инициатора изменений, чтобы его не обновлять) Да тут все проще зачем таймер если есть сигналы и слоты Просто я говорил проблема с индексами что нельзя корректно уведомить второе представление об изменениях в первом так как модельные индексы у них разные потому что они связаны с двумя моделями.................. И еще один ньюанс... не хотел пугать просто... Допустим мне захотелось сделать группировку списка задач по каким либо признакам... например по важности (в структуре Task есть такое поле importance) от (0 - 5) какое я щас вижу решение? делать еще одну связку модель + представление + делегат, передавать модели указатель на Storage с данными .........ну итд. То есть получается некислое дублирование кода, рост сложности кода проекта ну итд со всеми вытекающими.... И я так наверное и сделаю если никто ничего не посоветует выдающегося.... Эх где вы победители школьных олимпиад, эйнштейны, знатоки qt Извиняюсь за флуд... но мне почему то кажется что если бы эту тему увидел парень из troolteh котроый писал MVC фреймворк он бы сказал "Не парься брат делай void QAbstractItemModel::reset () для второй модели" |
|
Алексей1153 | Дата 4.8.2011, 10:48 |
проблема описана очень ясно и крупно: Цитата ПРОБЛЕМА!!! Данные в моделях и представлениях не синхронизируются между собой!!! <...> данные добавляются в QVector <Task> tasks; модель №2 уведомляется о том что данные добавились а вот модель и представление №1 НИЧЕГО ОБ ЭТОМ НЕ ЗНАЮТ по сути у тебя аналог окна виндового Explorer (дерево папок слева, содержимое папки - справа) только не для файловой системы, а для дерева проектов Ты упоминаешь, что передаёшь указатель на экземпляр своего класса. При изменениях меняется счётчик. Уведомлений, конечно же, никаких не произойдёт, их надо инициировать. Я бы сделал проверку по таймеру (скажем, раз в секунду) счётчика, и при его изменении обновлял бы представление, которое не в фокусе (тут спорный вопрос - наверное, вместе со счётчиком полезно запоминать инициатора изменений, чтобы его не обновлять) |
|
explorer85 | Дата 4.8.2011, 10:32 |
В том то и дело что я не могу врубиться как организовать правильную работу между своим классом и стандартными интерфейсами QAbstract**Model MVC фреймворка Qt!!! Не понимаю правильно я их настроил для работы (создал два подкласса QAbstractItemModel в них передал указатели на свой класс с данными итд, ну начинаю повторяться уже) Алексей1153 Ну вообще проблема ясно сформулирована? чтобы мне знать а то может быть и другие люди не поймут? |
|
Алексей1153 | Дата 4.8.2011, 10:27 |
explorer85, да, видимо я что-то не понимаю. Послежу | |
explorer85 | Дата 4.8.2011, 10:24 |
explorer85, мне тут вот что непонятно: массивы инкапсулированы. Если наружу не выдавать на них ссылок или указателей, то менять содержимое смогут только открытые функции CProjectLibrary. А это означает, что любое изменение можно отследить всегда. Все правильно, любое изменение можно отследить так как данные в массивах изменяются только с помощью открытых функции CProjectLibrary. Но проблема то не в этом!!! Еще раз повторюсь есть задача отображать эти данные в двух разных видах указанным способом...(в первом посте я все понятно обьяснил? может просто недопонимание какое то есть) Я нашел решение которое привел во 2 посте. Проблема в том что я не могу понять правильно ли я сделал применительно к философии mvc в qt или нет, и хочу спросить как бы вы решили эту проблему? Я ужасно извиняюсь, ну просто мне кажется что для понимания моей проблемы, нужен человек который имеет опыт написания собствеееных моделей производных от QAbstractItemModel и прокси QAbstractProxyModel Вот я конечно может быть много прошу но мне нужны как бы два ответа 1 теоретический, о правильности выбранной мной концепции 2 практический применительно этой концепции к конкретным классам QAbstract***Model в Qt Если же пресловутая модель (я не сталкивался ещё пока) не позволяет работать с таким классом совместно, то у меня возникают сомнения насчёт нужности этой самой модели в данном случае. В том то и дело что я не могу врубиться как организовать правильную работу со этим своим классом MVC фреймворка Qt!!! |
|
Алексей1153 | Дата 4.8.2011, 10:06 |
explorer85, мне тут вот что непонятно: массивы инкапсулированы. Если наружу не выдавать на них ссылок или указателей, то менять содержимое смогут только открытые функции CProjectLibrary. А это означает, что любое изменение можно отследить всегда. Если же пресловутая модель (я не сталкивался ещё пока) не позволяет работать с таким классом совместно, то у меня возникают сомнения насчёт нужности этой самой модели в данном случае. PS нэгодующая модэль : http://i9.photobucket.com/albums/a55/peppe...models/l152.jpg |
|
explorer85 | Дата 4.8.2011, 9:34 |
Алексей1153, спасибо за совет да с мапами пологичней и побыстрей. А насчет счтечика... дело в том что проекты и задачи отображаютя исключительно но через модели на представлениях и я их пробовал уведомлять сигналом , ну по аналогии с вашим счетчиком, но столкнулся с проблемой описанной в конце способа №1. Эх неужели никто всерьез не работал с моделями??? перечитал эту ветку за год похожие проблемы вроде встречались.... Неужели все в отпусках и на каникулах........ |
|
Просмотр темы полностью (откроется в новом окне) | |
Текстовая версия | Сейчас: 29.3.2024, 16:34 |