QAbstractItemView, или внутренности Qt |
Здравствуйте, гость ( Вход | Регистрация )
QAbstractItemView, или внутренности Qt |
Гость_Константин_* |
9.2.2009, 12:44
Сообщение
#11
|
Гости |
"старая" селекшн-модель может ещё использоваться ну с deleteLater она удалится после использования, когда управление вернется в режим "ожидания"
ы? Вот какая еще штука есть 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 |
ы? А где ты увидел выход в eventloop? Eventloop прерывается при входе в метод который вызывает setModel(), затем должен восстанавливаться уже после forever (если его убрать конечно). Там объекты и удалятся. это тупо кучка 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 |
Меня еще вот какой вопрос волнует. В Qt есть сигнал destroyed(), а вот created() нет. лучше отдельную тему для этогоА где ты увидел выход в 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:
это единственный список всех созданных объектов (с родителями и без), но в ТТ сказали, что его в будущих версиях будут убирать. |
|
|
SABROG |
9.2.2009, 14:38
Сообщение
#16
|
Профессионал Группа: Участник Сообщений: 1207 Регистрация: 8.12.2008 Из: Russia, Moscow Пользователь №: 446 Спасибо сказали: 229 раз(а) Репутация: 34 |
лучше отдельную тему для этого Раздели, если есть мысли по этому поводу. я думаю под Ы это и имелось в виду, когда выйдем в обработку событий, объект удалится, а мы его уже пользуем А в противном случае у нас другой косяк может возникнуть. Предположим мы получаем selectionModel и сохраняем указатель где-нибудь в другой переменной, затем делаем setModel(), а потом как ни в чем не бывало пытаемся использовать старую selectionModel. В итоге она будет возвращать всегда одни те же данные о выборе, что не будет соответствовать правде. И уйти от косяка кроме как прочитав предупреждение в ассистенте никак нельзя. это единственный список всех созданных объектов (с родителями и без), но в ТТ сказали, что его в будущих версиях будут убирать. 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 больше не нужна, то требуется её удалить. Сейчас в документации последних версий уже описывается в каких случаях это нужно делать и предлагается для этого два способа:
или с помощью 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.
|
|
|
Текстовая версия | Сейчас: 30.11.2024, 8:49 |