Форум на CrossPlatform.RU -> Ответ в QAbstractItemView, или внутренности Qt

Последние 10 сообщений [ в обратном порядке ]

Дмитрий -	Дата 2.8.2011, 17:07
	В документации для QAbstractItemView::setSelectionModel предлагается использовать deleteLater(), но вероятно имеется ввиду общий, универсальный случай. В моём случае, после задания TableView->setModel, я сразу в TableView->setSelectionModel задаю MyItemSelectionModel, а ItemSelectionModel созданная по умолчанию мне совсем не нужна и, поэтому я думаю, что её можно удалить с помощью просто delete.
wiz29	Дата 2.8.2011, 15:43
	разница именно в моменте удалении непосредственно самого объекта, в случае оператора delete объект будет удален сразу, в случае удаления посредством вызова deleteLater объект удалится, в момент передачи управления основному циклу обработки сообщений приложения, т.е. при таком вызове указатель на объект как правило еще валиден в рамках вызывающего участка кода. Что лучше использовать уже дело вкуса, если вариант с вызовом delete решает нужную задачу, то я выберу его.
Дмитрий -	Дата 2.8.2011, 14:52
	Подскажите пожалуйста что выбрать? Устанавливаю в 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();` Чем отличаются эти способы и какой лучше выбрать?
Константин	Дата 9.2.2009, 15:23
	я и не говорил, что к нему достучаться. в лучшем случае из него можно выдоить виджеты без родителя... но в отладочных целях можно влезть в код и наделать там гадостей
SABROG	Дата 9.2.2009, 14:38
	Цитата(Litkevich Yuriy @ 9.2.2009, 14:14) лучше отдельную тему для этого Раздели, если есть мысли по этому поводу. Цитата(Litkevich Yuriy @ 9.2.2009, 14:14) я думаю под Ы это и имелось в виду, когда выйдем в обработку событий, объект удалится, а мы его уже пользуем А в противном случае у нас другой косяк может возникнуть. Предположим мы получаем selectionModel и сохраняем указатель где-нибудь в другой переменной, затем делаем setModel(), а потом как ни в чем не бывало пытаемся использовать старую selectionModel. В итоге она будет возвращать всегда одни те же данные о выборе, что не будет соответствовать правде. И уйти от косяка кроме как прочитав предупреждение в ассистенте никак нельзя. Цитата(Гость_Константин_* @ 9.2.2009, 14:25) это единственный список всех созданных объектов (с родителями и без), но в ТТ сказали, что его в будущих версиях будут убирать. allObjects не помечен как extern, стало быть доступа к нему напрямую нету... Или у вас есть пример как достучаться?
Константин	Дата 9.2.2009, 14:25
	> А где ты увидел выход в 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); //... /` это единственный список всех созданных объектов (с родителями и без), но в ТТ сказали, что его в будущих версиях будут убирать.
Litkevich Yuriy	Дата 9.2.2009, 14:14
	Цитата(SABROG @ 9.2.2009, 16:59) Меня еще вот какой вопрос волнует. В Qt есть сигнал destroyed(), а вот created() нет. лучше отдельную тему для этого Цитата(SABROG @ 9.2.2009, 16:59) А где ты увидел выход в eventloop? Eventloop прерывается при входе в метод который вызывает setModel(), затем должен восстанавливаться уже после forever (если его убрать конечно). Там объекты и удалятся. я думаю под Ы это и имелось в виду, когда выйдем в обработку событий, объект удалится, а мы его уже пользуем
SABROG	Дата 9.2.2009, 13:59
	Цитата(Гость_Константин_* @ 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'ом.
Litkevich Yuriy	Дата 9.2.2009, 13:29
	я думаю, что можно было бы продолжить использовать имеющуюся модель выбора. Т.к. представления должны работать в главном потоке и как следствие связанные с ними модели. Поэтому если програмист меняет модель данных, то одновременно с этим он не работает с моделью выбора. Хотя, в прочем, я еще полноценно с модель/представление не работал, может в этом и нет особой надобности.
Константин	Дата 9.2.2009, 12:44
	Цитата(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>. полезной нагрузки мало.
Просмотр темы полностью (откроется в новом окне)