Получение значения выделенной ячейки tableView

@Darkvoid · Регистрация: 16.10.2012

Author24 — интернет-сервис помощи студентам

Всем доброго времени суток. Пишу программу на QT Creater, используя модели, требуется взять значение из 0 столбца, выделенной в данный момент строки. В функции double click таблицы, я его беру таким образом:

C++

//Двойной клик по dataTable
void MainWindow::on_tableView_doubleClicked(const QModelIndex &index)
{
    //Если работает админ и нужно отредактировать запись
    if(MyApp::isAdmin == 1)
    {
        QString qsBuffer = "";
        QString qsQuery = "";
 
        std::string sBuffer = "";
 
        int iIdRow = 0;
 
        //Получение индекса ячейки
        QModelIndex idIndex = ui->tableView->model()->index(index.row(), 0, index.parent());
 
        //Если индекс валиден
        if(idIndex.isValid())
        {
            //Конвертация значения в int
            iIdRow = idIndex.data().toInt();
 
            edit_record_v(qsBuffer, qsQuery, sBuffer, iIdRow);
        }
        else
        {
            return;
        }
    }
}

Тут никаких проблем, т.к. index определен заранее самой функцией двойного клика по таблице, мне же, мне же, требуется сделать то же самое, только под кнопку в меню. Делаю это так:

C++

//Кнопка изменить запись ERROR!!!
void MainWindow::on_action_edit_admin_triggered()
{
    QString qsBuffer = "";
    QString qsQuery = "";
 
    std::string sBuffer = "";
 
    int iIdRow = 0;
 
    //Получение индекса ячейки
 
    QModelIndex idIndex = ui->tableView->model()->index(ui->tableView->selectionModel()->currentIndex().row(),
                                                        0 , idIndex.parent());
 
    //Если индекс валиден
    if(idIndex.isValid())
    {
        //Конвертация значения в int
        iIdRow = idIndex.data().toInt();
 
        edit_record_v(qsBuffer, qsQuery, sBuffer, iIdRow);
    }
    else
    {
        return;
    }
}

Однако, не получается, что Я делаю не так, как получить индекс выделенной строки?

@Wyn · 16.01.2016, 18:20

Сообщение от Darkvoid

Однако, не получается, что Я делаю не так, как получить индекс выделенной строки?

А какой у тебя индекс выдаёт currentIndex?
Насколько понимаю - ставь selectionMode на SingleSelection, SelectionBehavior на QAbstractItemView::SelectRows, а затем через ui->tableView->selectedIndexes()->first() ты получаешь модельный индекс нулевого столба выделенной строки.

@Darkvoid · 16.01.2016, 20:05 **[ТС]**

Wyn, не работает
Вот скрин

@Wyn · 16.01.2016, 20:25

Сообщение от Darkvoid

Wyn, не работает
Вот скрин

У тебя там ошибка в parent Index.
Но зачем ты так делаешь? Я тебе прямо сказал, что ты по результату ui->tableView->selectedIndexes()->first() сразу получаешь индекс нулевого столбца(потому что selectionMode на SingleSelection и SelectionBehavior на SelectRows). Читай внимательнее, что тебе пишут.

Добавлено через 9 минут
Хотя там напрямую к selectedIndexes нельзя обратиться тк protected. Обращайся через selectionModel()->selectedIndexes()

Добавлено через 1 минуту
Только предварительно не забудь через selectionModel()->hasSelection() проверить что selection существует.

@Darkvoid · 16.01.2016, 21:21 **[ТС]**

Сообщение от Wyn

Хотя там напрямую к selectedIndexes нельзя обратиться тк protected. Обращайся через selectionModel()->selectedIndexes()

Чуток не догоняю, Я попробовал так сделать, но не работает, тип возвращаемого значения явно не int. Может нужно было создать сначала item, и туда пихать значение первой ячейки?

@Wyn · 16.01.2016, 23:37

Сообщение от Darkvoid

Чуток не догоняю, Я попробовал так сделать, но не работает, тип возвращаемого значения явно не int. Может нужно было создать сначала item, и туда пихать значение первой ячейки?

Есть чудесный сайт qt.io с чудесной документацией. К примеру в этой документации сказано, что QItemSelectionModel по запросу selectedIndexes() возвращает QModelIndexList. Список выбранных ModelIndex, понимаешь? И first из этого списка благодаря настройкам, что я тебе выше написал(ты же их поставил, верно?) вернёт первый ModelIndex выбранной строки - суть ModelIndex нулевого видимого столбца выбранной строки. Вроде бы он тебе изначально и был нужен?
И городить

C++ (Qt)

1	QModelIndex idIndex = ui->tableView->model()->index(ui->tableView->selectionModel()->currentIndex().row(), 0 , idIndex.parent());

В таком случае не надо. Можно просто написать

C++ (Qt)

1	QModelIndex idIndex = ui->tableView->model()->selectedIndexes()->first();

Я тебе это уже третий раз говорю...

Добавлено через 4 минуты
И в следующий раз, когда у тебя возникнет ещё вопрос по теме "почему не работает", то прежде чем его писать тут, я надеюсь, что ты ещё раз _внимательно_ перечитаешь всё мною здесь написанное. Может быть что-то из написанного мною ты просто забыл сделать(как например - поставить мною данные настройки или предварительно проверить на hasSelection() прежде чем пытаться достать несуществующий элемент этого самого selection с последующим сегфолтом. )

Добавлено через 2 минуты
Если будут ещё вопросы по данной теме, обращайся - помогу. Но, ради бога, читай то что я пишу внимательнее.

@Darkvoid · 18.01.2016, 10:44 **[ТС]**

Сообщение от Wyn

суть ModelIndex нулевого видимого столбца выбранной строки. Вроде бы он тебе изначально и был нужен?

А если Мне нужно значение скрытого нулевого столбца?

Добавлено через 32 минуты
Дело было к вечеру, делать было нечего, или как Я сонный пытался кодить, все работает, даже на скрытый столбец

C++

//Кнопка изменить запись
void MainWindow::on_action_edit_admin_triggered()
{
    QString qsBuffer = "";
    QString qsQuery = "";
 
    std::string sBuffer = "";
 
    int iIdRow = 0;
 
    //Получение индекса ячейки
 
    if(ui->tableView->selectionModel()->hasSelection())
    {
        QModelIndex idIndex = ui->tableView->selectionModel()->selectedIndexes().first();
 
        //Если индекс валиден
        if(idIndex.isValid())
        {
            //Конвертация значения в int
            iIdRow = idIndex.data().toInt();
 
            edit_record_v(qsBuffer, qsQuery, sBuffer, iIdRow);
        }
        else
        {
            return;
        }
    }
}

@Wyn · 18.01.2016, 11:48

Сообщение от Darkvoid

А если Мне нужно значение скрытого нулевого столбца?

А вот тут я не был уверен на 100%, потому как первый столбец никогда не скрывал в отображении. =)

@Darkvoid · 18.01.2016, 11:58 **[ТС]**

Сообщение от Wyn

А вот тут я не был уверен на 100%, потому как первый столбец никогда не скрывал в отображении. =)

id для юзвера не самая полезная информация и ее желательно скрывать

@Wyn · 18.01.2016, 13:58

Сообщение от Darkvoid

id для юзвера не самая полезная информация и ее желательно скрывать

Если мне однозначно не нужна была информация в отображении - я просто скрывал её в модели.
Если мне требовались операции над теми данными, которые были скрыты от отображения, то я делал дополнительные функции в модели, которые бы выполняли требуемые операции.

@OneMoreGres · 18.01.2016, 18:40

По мне так не лучший вариант.. Модель описывает данные. Если пользователю не нужно их видеть, это не значит, что модель должна о них забыть. А представление как раз и отвечает за то, как и что показывать пользователю.
Это не говоря о том, что в первом случае достаточно скрыть столбец в представлении стандартными методами, а для второго придется перегружать модель и изменять ее поведение.

@Wyn · 18.01.2016, 19:22

Сообщение от OneMoreGres

По мне так не лучший вариант.. Модель описывает данные. Если пользователю не нужно их видеть, это не значит, что модель должна о них забыть. А представление как раз и отвечает за то, как и что показывать пользователю.
Это не говоря о том, что в первом случае достаточно скрыть столбец в представлении стандартными методами, а для второго придется перегружать модель и изменять ее поведение.

Ок. Есть модель представления списка модулей, каждый из которых может быть добавлен/удалён/установлен/не установлен и т.д. Достаточно тривиальная задача, встречающаяся тут и там. Как её тогда предлагаешь делать, не расширяя интерфейс модели? Городя чёртову кучу скрытых столбцов?

Ведь главная задача MVC - это абстрагировать данные от отображения, предоставить к ним устойчивый интерфейс доступа и, если надо, их изменения. Отображение не должно знать что там за данные. Не знаю как остальные, но лично я считаю предоставление моделью внутренних данных, которые не должны использоваться отображением, - дурным тоном. Подобным образом отображение завязывается на конкретную структуру данных. А она сегодня может быть одна, а завтра примут решение, перепишут её на новый лад, добавив и изменив внутренние данные и придётся лезть в отображение, потому как старые внутренние данные не доступны или же ставить заглушку на них в модели. Костыли? Они самые. А зачем?

Впрочем случаи разные бывают - не спорю.

Добавлено через 16 минут
Кстати, если посмотреть на модели, унаследованные от QAbstractItemModel, то можно видеть как все они расширяют интерфейс в нужном для них направлении. Как пример - QSqlTableModel.

@OneMoreGres · 18.01.2016, 20:42

Для каждой ситуации свое решение. В данном случае лучше скрыть столбец с ИД, чем городить обходные пути для его получения. А если в другом представлении (для администратора) этот ИД понадобится, создавать новую модель, но уже с возможностью доступа к ИД в рамках QAbstractItemModel?

А так любая модель-потомок QAbstractItemModel уже абстрагировала сырые данные и предоставила для работы с ними фиксированный интерфейс. Если этого интерфейса недостаточно, тогда следует его расширять. А простое скрытие поля из модели это ни смена внутренней структуры, ни смена интерфейса. Для этого случае даже специальную модель придумали QSortFilterProxyModel.
Ну и, наконец, больше кода - больше вероятность ошибки и потраченных сил на его сопровождение

@Wyn · 18.01.2016, 22:35

Сообщение от OneMoreGres

Для каждой ситуации свое решение. В данном случае лучше скрыть столбец с ИД, чем городить обходные пути для его получения. А если в другом представлении (для администратора) этот ИД понадобится, создавать новую модель, но уже с возможностью доступа к ИД в рамках QAbstractItemModel?
А так любая модель-потомок QAbstractItemModel уже абстрагировала сырые данные и предоставила для работы с ними фиксированный интерфейс. Если этого интерфейса недостаточно, тогда следует его расширять. А простое скрытие поля из модели это ни смена внутренней структуры, ни смена интерфейса. Для этого случае даже специальную модель придумали QSortFilterProxyModel.
Ну и, наконец, больше кода - больше вероятность ошибки и потраченных сил на его сопровождение

Так я о том и говорю. Если в представлении ИД нужен - он моделью предоставляется. Если не нужен - не предоставляется. Модель ведь тоже не на ровно месте строится, а с учётом требований к ней. Мне подобный функционал был не нужен, зато требовался другой - я соответственно и делал. Но всё равно при этом я практически категорично уверен в том, что если визуально данные в отображении нигде не отображаются и планов на это нет - они моделью предоставляться отображению и не должны.

Как известно у модели может быть несколько отображений. Особенно это справедливо для мультиплатформенных программ. И обычно операции над моделью в отображениях более или менее одинаковы для всех отображений. И если они меняются - то меняются они для всех отображений. Вот честно, какой смысл содержать огромное количество дублируемого кода в разных отображениях, когда его можно разместить в модели? Уже не говоря о всем известных проблемах, которые такой дублируемый код вызывает. Поэтому я бы не стал так категорично утверждать, что тут именно проще скрывать столбец. Ему ведь отображение этого столбца не требуется. Вот честно, зачем всё это ему городить, искать индекс первого столбца, когда в модели можно просто взять и добавить функцию с необходимыми параметрами, которая будет сама, оперируя всей полнотой внутренних данных, всё делать? Это даже не считая того, что он там использует функцию редактирования какой-то записи. В прочем я не буду ему ничего советовать - у него там своя логика работы его программы в голове вертится - ему видней. Может это оправдано - может где-нибудь в другом представлении у него данный столбец отображается.
P.S. Честно говоря не видел ни одной серьёзной программы, в которой используются всегда скрытые столбцы(которые никогда не отображаются и не планируют отображаться). Ты такую программу можешь привести?

Насчёт QSortFilterProxyModel. Она всё же больше для того, для чего названа - для сортировки и фильтрации элементов по запросу из отображения(отображение само по себе не умеет этого делать) без каких-либо последствий для данных в реальной модели. Можно конечно использовать её отдельно и для такой маленькой задачи как фильтрация столбцов. Но смысл? Скрывать столбцы и отображение умеет. Зачем городить лишний код?

@OneMoreGres · 19.01.2016, 08:51

Можно, конечно, еще поспорить (практически по каждому пункту), но мы в основном говорим об одном и том же, хотя и расставляем акценты на разных вещах. Да и к теме это относится все меньше и меньше.
Впрочем, если есть желание, можно продолжить через ЛС

@Wyn 1070 / 652 / 229 Регистрация: 14.01.2016 Сообщений: 2,031 Записей в блоге: 9
	18.01.2016, 22:35	14
	Сообщение от OneMoreGres Для каждой ситуации свое решение. В данном случае лучше скрыть столбец с ИД, чем городить обходные пути для его получения. А если в другом представлении (для администратора) этот ИД понадобится, создавать новую модель, но уже с возможностью доступа к ИД в рамках QAbstractItemModel? А так любая модель-потомок QAbstractItemModel уже абстрагировала сырые данные и предоставила для работы с ними фиксированный интерфейс. Если этого интерфейса недостаточно, тогда следует его расширять. А простое скрытие поля из модели это ни смена внутренней структуры, ни смена интерфейса. Для этого случае даже специальную модель придумали QSortFilterProxyModel. Ну и, наконец, больше кода - больше вероятность ошибки и потраченных сил на его сопровождение Так я о том и говорю. Если в представлении ИД нужен - он моделью предоставляется. Если не нужен - не предоставляется. Модель ведь тоже не на ровно месте строится, а с учётом требований к ней. Мне подобный функционал был не нужен, зато требовался другой - я соответственно и делал. Но всё равно при этом я практически категорично уверен в том, что если визуально данные в отображении нигде не отображаются и планов на это нет - они моделью предоставляться отображению и не должны. Как известно у модели может быть несколько отображений. Особенно это справедливо для мультиплатформенных программ. И обычно операции над моделью в отображениях более или менее одинаковы для всех отображений. И если они меняются - то меняются они для всех отображений. Вот честно, какой смысл содержать огромное количество дублируемого кода в разных отображениях, когда его можно разместить в модели? Уже не говоря о всем известных проблемах, которые такой дублируемый код вызывает. Поэтому я бы не стал так категорично утверждать, что тут именно проще скрывать столбец. Ему ведь отображение этого столбца не требуется. Вот честно, зачем всё это ему городить, искать индекс первого столбца, когда в модели можно просто взять и добавить функцию с необходимыми параметрами, которая будет сама, оперируя всей полнотой внутренних данных, всё делать? Это даже не считая того, что он там использует функцию редактирования какой-то записи. В прочем я не буду ему ничего советовать - у него там своя логика работы его программы в голове вертится - ему видней. Может это оправдано - может где-нибудь в другом представлении у него данный столбец отображается. P.S. Честно говоря не видел ни одной серьёзной программы, в которой используются всегда скрытые столбцы(которые никогда не отображаются и не планируют отображаться). Ты такую программу можешь привести? Насчёт QSortFilterProxyModel. Она всё же больше для того, для чего названа - для сортировки и фильтрации элементов по запросу из отображения(отображение само по себе не умеет этого делать) без каких-либо последствий для данных в реальной модели. Можно конечно использовать её отдельно и для такой маленькой задачи как фильтрация столбцов. Но смысл? Скрывать столбцы и отображение умеет. Зачем городить лишний код? 0

@OneMoreGres 72 / 72 / 33 Регистрация: 07.11.2015 Сообщений: 281
	19.01.2016, 08:51	15
	Можно, конечно, еще поспорить (практически по каждому пункту), но мы в основном говорим об одном и том же, хотя и расставляем акценты на разных вещах. Да и к теме это относится все меньше и меньше. Впрочем, если есть желание, можно продолжить через ЛС 0

Получение значения выделенной ячейки tableView

Решение

Решение

@Wyn 1070 / 652 / 229 Регистрация: 14.01.2016 Сообщений: 2,031 Записей в блоге: 9
	16.01.2016, 18:20	2
	Сообщение от Darkvoid Однако, не получается, что Я делаю не так, как получить индекс выделенной строки? А какой у тебя индекс выдаёт currentIndex? Насколько понимаю - ставь selectionMode на SingleSelection, SelectionBehavior на QAbstractItemView::SelectRows, а затем через ui->tableView->selectedIndexes()->first() ты получаешь модельный индекс нулевого столба выделенной строки. 1

@Darkvoid 8 / 8 / 10 Регистрация: 16.10.2012 Сообщений: 523
	16.01.2016, 20:05 [ТС]	3
	Wyn, не работает Вот скрин Миниатюры 0

@Wyn 1070 / 652 / 229 Регистрация: 14.01.2016 Сообщений: 2,031 Записей в блоге: 9
	16.01.2016, 20:25	4
	Сообщение было отмечено Darkvoid как решение Решение Сообщение от Darkvoid Wyn, не работает Вот скрин У тебя там ошибка в parent Index. Но зачем ты так делаешь? Я тебе прямо сказал, что ты по результату ui->tableView->selectedIndexes()->first() сразу получаешь индекс нулевого столбца(потому что selectionMode на SingleSelection и SelectionBehavior на SelectRows). Читай внимательнее, что тебе пишут. Добавлено через 9 минут Хотя там напрямую к selectedIndexes нельзя обратиться тк protected. Обращайся через selectionModel()->selectedIndexes() Добавлено через 1 минуту Только предварительно не забудь через selectionModel()->hasSelection() проверить что selection существует. 1

@Darkvoid 8 / 8 / 10 Регистрация: 16.10.2012 Сообщений: 523
	16.01.2016, 21:21 [ТС]	5
	Сообщение от Wyn Хотя там напрямую к selectedIndexes нельзя обратиться тк protected. Обращайся через selectionModel()->selectedIndexes() Чуток не догоняю, Я попробовал так сделать, но не работает, тип возвращаемого значения явно не int. Может нужно было создать сначала item, и туда пихать значение первой ячейки? Миниатюры 0

@Wyn 1070 / 652 / 229 Регистрация: 14.01.2016 Сообщений: 2,031 Записей в блоге: 9
	18.01.2016, 11:48	8
	Сообщение от Darkvoid А если Мне нужно значение скрытого нулевого столбца? А вот тут я не был уверен на 100%, потому как первый столбец никогда не скрывал в отображении. =) 0

@Darkvoid 8 / 8 / 10 Регистрация: 16.10.2012 Сообщений: 523
	18.01.2016, 11:58 [ТС]	9
	Сообщение от Wyn А вот тут я не был уверен на 100%, потому как первый столбец никогда не скрывал в отображении. =) id для юзвера не самая полезная информация и ее желательно скрывать 0

@Wyn 1070 / 652 / 229 Регистрация: 14.01.2016 Сообщений: 2,031 Записей в блоге: 9
	18.01.2016, 13:58	10
	Сообщение от Darkvoid id для юзвера не самая полезная информация и ее желательно скрывать Если мне однозначно не нужна была информация в отображении - я просто скрывал её в модели. Если мне требовались операции над теми данными, которые были скрыты от отображения, то я делал дополнительные функции в модели, которые бы выполняли требуемые операции. 0

@OneMoreGres 72 / 72 / 33 Регистрация: 07.11.2015 Сообщений: 281
	18.01.2016, 18:40	11
	По мне так не лучший вариант.. Модель описывает данные. Если пользователю не нужно их видеть, это не значит, что модель должна о них забыть. А представление как раз и отвечает за то, как и что показывать пользователю. Это не говоря о том, что в первом случае достаточно скрыть столбец в представлении стандартными методами, а для второго придется перегружать модель и изменять ее поведение. 0

@Wyn 1070 / 652 / 229 Регистрация: 14.01.2016 Сообщений: 2,031 Записей в блоге: 9
	18.01.2016, 19:22	12
	Сообщение от OneMoreGres По мне так не лучший вариант.. Модель описывает данные. Если пользователю не нужно их видеть, это не значит, что модель должна о них забыть. А представление как раз и отвечает за то, как и что показывать пользователю. Это не говоря о том, что в первом случае достаточно скрыть столбец в представлении стандартными методами, а для второго придется перегружать модель и изменять ее поведение. Ок. Есть модель представления списка модулей, каждый из которых может быть добавлен/удалён/установлен/не установлен и т.д. Достаточно тривиальная задача, встречающаяся тут и там. Как её тогда предлагаешь делать, не расширяя интерфейс модели? Городя чёртову кучу скрытых столбцов? Ведь главная задача MVC - это абстрагировать данные от отображения, предоставить к ним устойчивый интерфейс доступа и, если надо, их изменения. Отображение не должно знать что там за данные. Не знаю как остальные, но лично я считаю предоставление моделью внутренних данных, которые не должны использоваться отображением, - дурным тоном. Подобным образом отображение завязывается на конкретную структуру данных. А она сегодня может быть одна, а завтра примут решение, перепишут её на новый лад, добавив и изменив внутренние данные и придётся лезть в отображение, потому как старые внутренние данные не доступны или же ставить заглушку на них в модели. Костыли? Они самые. А зачем? Впрочем случаи разные бывают - не спорю. Добавлено через 16 минут Кстати, если посмотреть на модели, унаследованные от QAbstractItemModel, то можно видеть как все они расширяют интерфейс в нужном для них направлении. Как пример - QSqlTableModel. 0

@OneMoreGres 72 / 72 / 33 Регистрация: 07.11.2015 Сообщений: 281
	18.01.2016, 20:42	13
	Для каждой ситуации свое решение. В данном случае лучше скрыть столбец с ИД, чем городить обходные пути для его получения. А если в другом представлении (для администратора) этот ИД понадобится, создавать новую модель, но уже с возможностью доступа к ИД в рамках QAbstractItemModel? А так любая модель-потомок QAbstractItemModel уже абстрагировала сырые данные и предоставила для работы с ними фиксированный интерфейс. Если этого интерфейса недостаточно, тогда следует его расширять. А простое скрытие поля из модели это ни смена внутренней структуры, ни смена интерфейса. Для этого случае даже специальную модель придумали QSortFilterProxyModel. Ну и, наконец, больше кода - больше вероятность ошибки и потраченных сил на его сопровождение 0