crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )

2 страниц V  < 1 2  
Ответить в данную темуНачать новую тему
> Очень интересная проблема проектирования, Надеюсь на помощь гуру
Алексей1153
  опции профиля:
сообщение 4.8.2011, 11:30
Сообщение #11


фрилансер
******

Группа: Участник
Сообщений: 2939
Регистрация: 19.6.2010
Из: Обливион
Пользователь №: 1822

Спасибо сказали: 215 раз(а)




Репутация:   34  


Цитата
Хотя интересно как там сделано))

да очень просто всё сделано (кхм, если работу с АПИшными Tree View и List View можно вообще назвать простыми. Это ад! Но ад программистский, а не
логический) - я делал такую вещь для одной из программ (не на Qt). Главное: отделить GUI от логики и от данных. Окно лишь показывает текущее
состояние данных, а также позволяет ввести новые данные (для создания нового элемента либо для замены содержимого существующего). После
изменения данных окно должно перерисоваться, чтобы показать текущее содержимое данных. Под перерисовкой понимается не принудительная
перерисовка всего, а, возможно, перерисовка только необходимой части окна для отображения изменений. Но само окно понятия не имеет, что поменялось!
Даже несмотря на то, что именно окно помогло ввести данные. Хранилищем окно не управляет - оно передало введённую информацию и забыло.
Перерисовалось. Типа - "я сделало всё, что могло, сотрите, что теперь в данных".
Оба окна не зависят друг от друга. Они зависят от данных. А то, как сортировать, это уже просто - выводят содержимое данных в том виде, в каком
пользователь попросил.

Цитата
зачем таймер если есть сигналы и слоты

если получится - пожалуйста. но я бы не стал городить сложную систему оповещений там, где она не нужна. По опыту знаю, что в данном случае проверка
по таймеру - достаточно. И сильно упрощает. Если непонятно рассказываю, могу схемку накидать ))

Цитата
какое я щас вижу решение? делать еще одну связку модель + представление + делегат, передавать модели указатель на Storage с данными
.........ну итд. То есть получается некислое дублирование кода, рост сложности кода проекта ну итд со всеми вытекающими.... И

таймер вновь спешит на помощь :) Сменишь счётчик вхолостую и всё готово.
Кстати говоря, таймер то таймером, он обновит раз в секунду, что нормально для обновления вида других окон (не в фокусе), но не очень то для текущего
окна (сказали сортировать - а оно отреагировало через секунду...) . Тут делаем так: то, что вызывается в обработчике таймера для обновления окон, надо
иметь возможность вызвать в любой момент. Увеличили счётчик вхолостую, вызвали процедуру. Дальше всё по накатанной

Сообщение отредактировал Алексей1153 - 4.8.2011, 11:31
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
explorer85
  опции профиля:
сообщение 4.8.2011, 12:14
Сообщение #12


Студент
*

Группа: Новичок
Сообщений: 12
Регистрация: 18.3.2011
Пользователь №: 2517

Спасибо сказали: 0 раз(а)




Репутация:   0  


Спасибо за ответы, но просто для всего что вы описали в mvc qt есть стандартные вещи: dataChanged, Begin..EndInsertRows итд. Просто оно как бы все уже есть но вот правильно ли я этим пользуюсь в своей ситуации я не знаю.
Вообще по жизни стараюсь придерживаться правила не изобретать велосипеды и если есть что то готовое пользоваться этим. Но за соблюдение этого правила, приходиться расплачиваться необходимостью подстраиваться под чужие уже написанные решения.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
PAFOS
  опции профиля:
сообщение 5.8.2011, 13:53
Сообщение #13


Активный участник
***

Группа: Участник
Сообщений: 258
Регистрация: 27.12.2010
Из: Дмитров
Пользователь №: 2309

Спасибо сказали: 29 раз(а)




Репутация:   8  


Для начала я бы сделал одну модель и два представления. Как ни крути делать две модели для одних и тех же данных неправильно.
Модель будет иметь иерархическую структуру

Проект1
Задача 1
Задача 2
Проект2
Задача 3
Без проекта
Задача 4

Реализация такой модели - дело практики.

Идем далее...

struct Task
{
    int TaskID;
    int ProjectID;
    QString Name;
    QString Notes;
    int Importance;
.......
};

struct Project
{
    int ProjectID;
    QString Name;
    QString Notes;
........
};


заменяем на

struct Task
{
    int TaskID;
    int ProjectID;
    QString Name;
    QString Notes;
    int Importance;

    Project *project  // <- имея на руках экземпляр Task, можем получить доступ к проекту вообще без гемора
.......
};

struct Project
{
    int ProjectID;
    QVector<Task> tasks // <- ну это как бы понятно)
    QString Name;
    QString Notes;
........
};


Такая структура существенно сократит реализацию модели
Однако надо быть внимательным с указателями и т.п.

И напоследок:

Если посмотреть внимательно на класс QAbstractItemView, то можно найти классный метод setRootIndex( QModelIndex )
Для древовидного представления setRootIndex() должен быть QModelIndex::invalid() (т.е. корень модели)
А для списка - выделенный в древовидном представлении QModelIndex типа "Проект".

Сообщение отредактировал PAFOS - 5.8.2011, 13:55
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение

2 страниц V  < 1 2
Быстрый ответОтветить в данную темуНачать новую тему
Теги
Нет тегов для показа


1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0




RSS Текстовая версия Сейчас: 28.3.2024, 13:07