Russian Qt Forum

До 1-го вызова QTableView::setMode, QTableView::selectionModel() == NULL
Явно баг.

C++ (Qt)
QTableView* TableView = new QTableView(this);
QItemSelectionModel* Selection = TableView->selectionModel(); // == NULL
TableView->setModel(NULL);
Selection = TableView->selectionModel(); // GOOD
 

Я хочу сказать это прелестно :) Еще бы знать зачем обращаться к модели выделения до установки модели данных (баг то понятен, небольшой поиск по исходникам все проясняет). Я например представление создаю через строитель, которому передается модель, а он создает представление, настраивает его, привязывает модель, формирует делегаты, навешивает на него дополнительных обработчиков, а потом отдает вызывающей стороне.

Зачем обращаться, это уже другой вопрос.
Мне вот понадобилось передать SelectionModel в коструктор модели(QAbstractItemModel), для упрощения реализации.

Хотя баг несущественен, скорее фича, поскольку при смене QAbstractItemModel - QItemSelectionModel тоже должна смениться.

Ага, вот прочитал предыдущее сообщение и удивился как это, в QAbstractItemView::setModel есть строка     setSelectionModel(new QItemSelectionModel(d->model, this));
Поэтому предыдущий указатель будет невалидным.
Интересно кстати знать зачем модели информация о выделении.

Например, у меня.
Модель - список. На View селекция строками целиком, любых и в любом кол-ве. View может быть  только одно!
Есть команды(на уровне модели) переместить выделенное на строку вверх, вниз и удалить, есть проверки, какие команды возможны в данный момент. В данной схеме проще для модели знать SelectionModel.
А вообще, данная QT концепция с SelectionModel представляется мне весьма сомнительной.
На мой взгляд QItemSelectionModel и QAbstractItemModel должны быть объеденены.
Мало того что редко требуется установка одной модели в разные view одновременно, еще реже эти view должны иметь разную селекцию. Для таких случаев достаточно что-то типа Proxy.
Гораздо чаще базовые данные модели уже изначально имеют свою селекцию(как правило что-то типа Item Index или Indexes), а модель ничего не может об этом сообщить, поскольку она ни о View ни о SelectionModel ничего не знает.

Ну и что мешает задействовать сигналы предоставляемые QItemSelectionModel? Там есть все нужное. ООП же, не надо все сваливать в один класс: композиция и взаимодействие! :)

С сигналами от View на запрос к модели для возможной смены селекции я согласен, но политика селекции зависит от не от View, а от базовых данных модели. А QItemSelectionModel это уровень View, но не модели.
1) Данные могут не позволять делать определенного вида селекции.
2) Данные могут нести изначально свою селекцию и обязаны поддерживать ее актуальной.
    Например, у меня есть списочные данные которые если список не пуст обязаны иметь актуальный ItemIndex >= 0.
    И даже при установке модели с такими данными во View приходится делать танец с бубном:
    - Создаем модель, устанавливаем в нее данные(или создаем модель от данных)
    - Устанавливаем модель во View
    - Запрашиваем у данных их текущую селекцию и устанавливаем ее в SelectionModel, при этом иногда необходимо блокировать обратную связь от SelectionModel на смену селекции.
    - При смене селекции у данных вне View, где-то в другом месте, танец повторяется.
3) Смена селекции у данных может происходить не только через View, но и другими способами.

А по-моему всё логично: нет модели, нечего выделять.

@spectre71 Я в аналогичном случае, сделал класс контроллер, который перемещает строки, и класс контроллер, который следит за тем, какие операции доступны. Я их могу в разных вариантах с разными моделями комбинировать, а вам придётся втыкать одинаковый код в каждую модель. Не зря же придумали MVC, а вы хотите модель и контроллер объединить, вот и получаются проблемы.

Эмм а что если эти функции реализовать в наследнике QItemSelectionModel?

QItemSelectionModel - это уровень View, а не модели(данных). Это примерно так же неправильно как запихивать данные в наследника View.
Данные и модель должны регулировать политику селекции, и некоторое поведение View, а не наоборот.
И опять же модель(данные) не знает о SelectionModel(даже о специализированной), управлять селекцией должна модель(данные), а не примочка сверху.

Да, отклонились мы от темы.
Я считаю что данные не должны задавать сложную логику их обработки, для этого есть контроллер (в Qt его в чистом виде нет, он размазан по QItemSelectionModel, делегатам и представлениям). Но поскольку наши подходы не совпадают похоже помочь в решении задачи я не смогу.

Да собственно помогать и не надо. Просто приходиться извращаться, что и делаем.

так и не понял: при чём тут мешок?