QStandardModel и сигнал rowsInserted() Опции

[Анна]

Столкнулась с таким фактом:
Если QStandardModel использую как таблицу и добавляю ряды непосредственно в саму модель с помощью QStandardModel::appendRow(), то в слоте, присоединённом к сигналу rowsInserted( const QModelIndex & parent, int start, int end) нет возможности добраться до данных, которые вставлены. parent не валидный, его указатель на модель равен нулю. Теоретически можно выловить модель из sender(), но где гарантия, что мой слот подсоединён к сигналу непоспедственно от модели, а не через какого-нибудь посредника?
Кто может посоветовать что-нибудь , как решить проблему доставания данных из этого сигнала?

[lanz]

Можно сохранять ссылку на модель внутри получателя сигнала. Тем более если есть некие посредники.
Либо как раз использовать посредника, который связан с моделью и выдает сигнал (QAbstractItemModel*, int, int) например.

[Анна]

Можно сохранять ссылку на модель внутри получателя сигнала. Тем более если есть некие посредники.
Либо как раз использовать посредника, который связан с моделью и выдает сигнал (QAbstractItemModel*, int, int) например.

Можно, конечно.
Собственно, покопавшись и в QStandardModel и в прокси-модели для сортировки и во вьюверах, я обнаружила, что они не прльзуются данными этого сигнала, потому что имеют указатель на модель, и "танцуют"уже от неё. Хотя, в идеале указатель на модель должен приходить в индексе parent. Если бы авторы в parent, который указывает на рутовый (скрытый внутри модели) элемент, передавали бы модель, было бы гораздо легче.
В общем, моё резюме такое, QStandardModel можно исподьзовать только в самых примитивных случаях или применять какие-то искусственные приёмы. Например, для двумерной таблицы или списка сперва вставлять рутовый элемен, а на нём уже городить список или таблицу. Тогда parent в сигнале всегда будет валидным.
Лучший выход - писать свою модель.

[wiz29]

просто если добавляется строка верхнего уровня у нее естественно не будет валидного предка, тк это просто QModelIndex(). Можно конечно сделать фиктивный элемент дерева и настроить представления относительно этого элемента, если очень не хочется хранить данные на модель. Но на мой взгляд было бы правильней иметь все же данные об объекте в "приемнике" сообщения либо брать его через sender в этом нет ничего неприличного.

[Анна]

просто если добавляется строка верхнего уровня у нее естественно не будет валидного предка, тк это просто QModelIndex(). Можно конечно сделать фиктивный элемент дерева и настроить представления относительно этого элемента, если очень не хочется хранить данные на модель. Но на мой взгляд было бы правильней иметь все же данные об объекте в "приемнике" сообщения либо брать его через sender в этом нет ничего неприличного.

Так и я ж об этом. В том-то и дело, что приходится мудрить.

Но на мой взгляд было бы правильней иметь все же данные об объекте в "приемнике" сообщения либо брать его через sender в этом нет ничего неприличного.

Что-то во мне протестует против этого "правильнее". Моему приёмнику правилнее было бы абсолютно наплевать, откуда его известили о новом элементе, а так, ему нужно держать указатели на модели, от которых может прийти сигнал, да ещё и иметь отдельный слот для каждой модели. А если использовать sender, то слотом уже невозможно воспользоваться как обычной функцией.

[lanz]

Для такого есть QSignalMapper.
http://qt-project.org/doc/qt-4.8/qsignalmapper.html