crossplatform.ru

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

2 страниц V  < 1 2  
Ответить в данную темуНачать новую тему
> QAbstractItemView, или внутренности Qt
Гость_Константин_*
сообщение 9.2.2009, 12:44
Сообщение #11





Гости








    


Цитата(SABROG @ 9.2.2009, 12:10) *
Цитата(Litkevich Yuriy @ 9.2.2009, 11:59) *
"старая" селекшн-модель может ещё использоваться

ну с deleteLater она удалится после использования, когда управление вернется в режим "ожидания"

        QTreeView *tree = new QTreeView(this);
        forever
        {
                QItemSelectionModel* sm = tree->selectionModel();
                tree->setModel(0);
                // предполагаем, что в setModel(...) выполнится sm->deleteLater;
                tree->setSelectionModel(sm); // типа, восстановили состояние выбора до сброса модели
        }

ы?


Цитата(SABROG @ 9.2.2009, 12:10) *
Вот какая еще штука есть QObjectCleanupHandler
Если ядро сама удалит какой-то QObject, то он автоматически удаляется из списка.

это тупо кучка QPointer<QObject>. полезной нагрузки мало.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Litkevich Yuriy
  опции профиля:
сообщение 9.2.2009, 13:29
Сообщение #12


разработчик РЭА
*******

Группа: Сомодератор
Сообщений: 9669
Регистрация: 9.1.2008
Из: Тюмень
Пользователь №: 64

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




Репутация:   94  


я думаю, что можно было бы продолжить использовать имеющуюся модель выбора. Т.к. представления должны работать в главном потоке и как следствие связанные с ними модели. Поэтому если програмист меняет модель данных, то одновременно с этим он не работает с моделью выбора. Хотя, в прочем, я еще полноценно с модель/представление не работал, может в этом и нет особой надобности.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
SABROG
  опции профиля:
сообщение 9.2.2009, 13:59
Сообщение #13


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

Группа: Участник
Сообщений: 1207
Регистрация: 8.12.2008
Из: Russia, Moscow
Пользователь №: 446

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




Репутация:   34  


Цитата(Гость_Константин_* @ 9.2.2009, 12:44) *
ы?


А где ты увидел выход в eventloop? Eventloop прерывается при входе в метод который вызывает setModel(), затем должен восстанавливаться уже после forever (если его убрать конечно). Там объекты и удалятся.

Цитата(Гость_Константин_* @ 9.2.2009, 12:44) *
это тупо кучка QPointer<QObject>. полезной нагрузки мало.

Этот класс для отладочных целей, позволяет контролировать/наблюдать жизнь объектов. Это не просто список, он динамический. Например ты добавил кучу кнопок на форму и решил отследить удалит ли их parent. После удаления родительской формы в этом списке не должно остаться ни одного объекта иначе мы делает вывод, что у нас утечка памяти или косяк где-то (например забыли передать предка).

Меня еще вот какой вопрос волнует. В Qt есть сигнал destroyed(), а вот created() нет. Интересно, есть ли возможность без наследования получить список всех QObject'ов в программе или по крайней мере создать такой список? При этом не обязательно, что QObject имеет parent'a или является QWidget'ом.

Сообщение отредактировал SABROG - 9.2.2009, 14:02
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Litkevich Yuriy
  опции профиля:
сообщение 9.2.2009, 14:14
Сообщение #14


разработчик РЭА
*******

Группа: Сомодератор
Сообщений: 9669
Регистрация: 9.1.2008
Из: Тюмень
Пользователь №: 64

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




Репутация:   94  


Цитата(SABROG @ 9.2.2009, 16:59) *
Меня еще вот какой вопрос волнует. В Qt есть сигнал destroyed(), а вот created() нет.
лучше отдельную тему для этого

Цитата(SABROG @ 9.2.2009, 16:59) *
А где ты увидел выход в eventloop? Eventloop прерывается при входе в метод который вызывает setModel(), затем должен восстанавливаться уже после forever (если его убрать конечно). Там объекты и удалятся.
я думаю под Ы это и имелось в виду, когда выйдем в обработку событий, объект удалится, а мы его уже пользуем
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Гость_Константин_*
сообщение 9.2.2009, 14:25
Сообщение #15





Гости








    


> А где ты увидел выход в eventloop?
согласен, с примером оплошал. но и tree->setSelectionModel(sm) не обязательно может выполнятся синхронно :)
правда, это уже абсурдинкой попахивает...наверное, просто не рассчитана вьюха на подобные передёргивания источника - и всё тут...


> Интересно, есть ли возможность без наследования получить список всех QObject'ов в программе или по крайней мере создать такой список? При этом не обязательно, что QObject имеет parent'a или является QWidget'ом.

see src/corelib/kernel/qobject.cpp:
/*
let's see src/corelib/kernel/qobject.cpp:

Q_GLOBAL_STATIC (QObjectSet, allObjects)

extern "C" Q_CORE_EXPORT void qt_addObject(QObject *object)

   QWriteLocker locker(qt_object_read_write_lock());
   QObjectSet *set = allObjects();
   if (set)
       set->insert(object);

//...
QObject::QObject(QObject *parent)
   : d_ptr(new QObjectPrivate)

   Q_D(QObject);
   qt_addObject(d_ptr->q_ptr = this);
//...
*/

это единственный список всех созданных объектов (с родителями и без), но в ТТ сказали, что его в будущих версиях будут убирать.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
SABROG
  опции профиля:
сообщение 9.2.2009, 14:38
Сообщение #16


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

Группа: Участник
Сообщений: 1207
Регистрация: 8.12.2008
Из: Russia, Moscow
Пользователь №: 446

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




Репутация:   34  


Цитата(Litkevich Yuriy @ 9.2.2009, 14:14) *
лучше отдельную тему для этого

Раздели, если есть мысли по этому поводу.

Цитата(Litkevich Yuriy @ 9.2.2009, 14:14) *
я думаю под Ы это и имелось в виду, когда выйдем в обработку событий, объект удалится, а мы его уже пользуем

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

Цитата(Гость_Константин_* @ 9.2.2009, 14:25) *
это единственный список всех созданных объектов (с родителями и без), но в ТТ сказали, что его в будущих версиях будут убирать.


allObjects не помечен как extern, стало быть доступа к нему напрямую нету... Или у вас есть пример как достучаться?

Сообщение отредактировал SABROG - 9.2.2009, 14:48
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Константин
  опции профиля:
сообщение 9.2.2009, 15:23
Сообщение #17


Студент
*

Группа: Участник
Сообщений: 69
Регистрация: 9.2.2009
Пользователь №: 539

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




Репутация:   1  


я и не говорил, что к нему достучаться. в лучшем случае из него можно выдоить виджеты без родителя...
но в отладочных целях можно влезть в код и наделать там гадостей :)
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Дмитрий -
  опции профиля:
сообщение 2.8.2011, 14:52
Сообщение #18


Новичок


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

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




Репутация:   0  


Подскажите пожалуйста что выбрать? Устанавливаю в TableView новую ItemSelectionModel. Так как старая ItemSelectionModel больше не нужна, то требуется её удалить. Сейчас в документации последних версий уже описывается в каких случаях это нужно делать и предлагается для этого два способа:
 QItemSelectionModel *OldSelectionModel = view->selectionModel();
view->setSelectionModel(new MyItemSelectionModel(view->model));
delete OldSelectionModel;

или с помощью deleteLater():

 view->selectionModel()->deleteLater();
view->setSelectionModel(new MyItemSelectionModel(view->model));
          а может быть правильно так:
QItemSelectionModel *OldSelectionModel = view->selectionModel();
view->setSelectionModel(new MyItemSelectionModel(view->model));
OldSelectionModel->deleteLater();

Чем отличаются эти способы и какой лучше выбрать?
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
wiz29
  опции профиля:
сообщение 2.8.2011, 15:43
Сообщение #19


Старейший участник
****

Группа: Участник
Сообщений: 600
Регистрация: 7.7.2010
Из: Санкт-Петербург
Пользователь №: 1866

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




Репутация:   12  


разница именно в моменте удалении непосредственно самого объекта, в случае оператора delete объект будет удален сразу, в случае удаления посредством вызова deleteLater объект удалится, в момент передачи управления основному циклу обработки сообщений приложения, т.е. при таком вызове указатель на объект как правило еще валиден в рамках вызывающего участка кода. Что лучше использовать уже дело вкуса, если вариант с вызовом delete решает нужную задачу, то я выберу его.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Дмитрий -
  опции профиля:
сообщение 2.8.2011, 17:07
Сообщение #20


Новичок


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

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




Репутация:   0  


В документации для QAbstractItemView::setSelectionModel предлагается использовать deleteLater(), но вероятно имеется ввиду общий, универсальный случай. В моём случае, после задания TableView->setModel, я сразу в TableView->setSelectionModel задаю MyItemSelectionModel, а ItemSelectionModel созданная по умолчанию мне совсем не нужна и, поэтому я думаю, что её можно удалить с помощью просто delete.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение

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


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




RSS Текстовая версия Сейчас: 30.11.2024, 8:49