Russian Qt Forum
Сентябрь 25, 2024, 01:18 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: [1]   Вниз
  Печать  
Автор Тема: Таблицы, модели, отображения  (Прочитано 5095 раз)
alammer
Гость
« : Ноябрь 23, 2012, 08:57 »

Здравствуйте!Я с QT дружу недавно, с принципами model/view и того меньше, поэтому хотелось бы приобщиться к мудрости настоящих гуру:)

Пишу ГУИ под следующую задачу:

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

б)Пакеты должны выводиться на экран в виде таблицы в реальном или близком к реальному времени. Принцип отображения тот же. Уникальный ключ пакета - добавляем новую строку в таблицу, повторяющийся пакет - обновляем отдельные поля(столбцы). Для пользователя таблица будет рид-онли, никакого ручного редактирования, только сортировка или фильтрация экранного вывода по выбранным полям. Вывод на данный момент осуществляется через QTableView.

Вопросы:
1) Имеет ли смысл при такой постановки задачи создавать и поддерживать отдельную модель данных для экранного представления?
Или проще будет сначала все в БД загонять, а уже из нее на экран выводить?

Изначально предполагалось, что основной упор в программе будет сделан именно на отображении пакетов, а работа с БД будет происходить в фоновом режиме и заключатся главным образом в инсерте/апдейте. Сейчас уже сомневаюсь в практичности параллельного существования БД и модели данных для экрана.

2)вопрос сугубо ламмерский и к первому напрямую не относящийся:
в главном окне есть кнопка1, прописаная в хидере как

private slots:
    void on_Button1_clicked();

в файле исходника в теле

void MainWindow::on_Button1_clicked()
{
вызываю через указатель на модель func1() из класса модели
}

внутри func1 вызываю
{
...............
beginInsertRows(*tmpIndex,row,row);
//добавляем данные в модель
endInsertRows();
return 0;
}

почему обновление на экране таблицы связанной с моделью происходит только после выхода из on_Button1_clicked()?


Записан
Bepec
Гость
« Ответ #1 : Ноябрь 23, 2012, 09:21 »

2) потому что команды выполняются последовательно. У вас синхронный интерфейс

Для примера
Код:
void MainWindow::on_Button1_clicked()
{
// начало ф-ции клика
func1();
      // func1 вызов
      {
      ...............
      beginInsertRows(*tmpIndex,row,row);
      //добавляем данные в модель
      endInsertRows();
      return 0;
      }
      // конец func1 вызова
// конец ф-ции клика
}
Записан
Kurles
Бывалый
*****
Offline Offline

Сообщений: 480



Просмотр профиля
« Ответ #2 : Ноябрь 23, 2012, 09:24 »

1) А что мешает в одной модели и слежение за источником данных организовать, и вставку/обновление в бд и вывод на экран?
Записан

Код
C++ (Qt)
while(!asleep()) sheep++;
retif
Гость
« Ответ #3 : Декабрь 15, 2012, 18:19 »

Чтобы не создавать отдельную тему.

Есть оригинальная модель (получает результат выполнения SQL-запроса) и промежуточная модель.

Код:
// оригинальная модель
QSqlQueryModel *model = new QSqlQueryModel();

// ... выполняется запрос, присваивается модель результата ...

// промежуточная модель
QSortFilterProxyModel *proxah = new QSortFilterProxyModel();
proxah->setSourceModel(model);

proxah->setHeaderData(0, Qt::Horizontal, tr("Тип"));
proxah->setHeaderData(1, Qt::Horizontal, tr("Статус"));
// ... и так далее

Изменение заголовков у промежуточной модели методом setHeaderData() также изменяет заголовки оригинальной модели. Я не понимаю, ведь она же для того и прокси, чтобы не трогать оригинал? Или нет?
Записан
mutineer
Гость
« Ответ #4 : Декабрь 15, 2012, 18:56 »

Цитировать
Any changes made through the QSortFilterProxyModel are applied to the original model.

Эта конкретная прокси-модель предназначена для фильтрации/сортировки, а не для хранения каких-либо данных, поэтому все изменения транслируются в исходную модель
Записан
retif
Гость
« Ответ #5 : Декабрь 15, 2012, 21:48 »

Но и обычная QProxyModel тоже изменяет оригинал. Какую же использовать?
Записан
mutineer
Гость
« Ответ #6 : Декабрь 15, 2012, 22:01 »

Отнаследуйся и реализуй нужное поведение. QProxyModel это устаревший класс, кстати
Записан
retif
Гость
« Ответ #7 : Декабрь 16, 2012, 10:38 »

Понятно, значит, наследоваться. Просто я понадеялся, что прокси совершенно никак не влияет на оригинал.

Да, я видел в справке, что QProxyModel не рекомендуется к использованию, как устаревший.
Ещё тогда вопрос: из базовых классов что лучше использовать вместо него? Что пришло ему на замену?
Записан
mutineer
Гость
« Ответ #8 : Декабрь 16, 2012, 10:42 »

QAbstractProxyModel юзай. Если сортировка/фильтрация все же нужна, то наследуйся от QSortFilterProxyModel
Записан
Страниц: [1]   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.327 секунд. Запросов: 23.