проблема с DataS »

[Subst]

У меня проблема следующая:

m_report->dataManager()->addModel(...) замечательно работает. Но до тех пор, пока я не сделаю локализацию, после этого
в списке полей отчета пропадает оригинально название поля, но появляется локализованное.

скажем поле city. В программе код setHeaderData(fieldIndex("city"),tr("City"));

Вот в limeReport и отображается как tr("City"), если в локализации Это "Город", то и будет Город. Крайне неудобно и похоже на баг (ну или фичу, если угодно ).

т.е. сделал отчет, локализовал программу - отчет заново творить. Сделал перевод на иной язык - отчет заново творить.

Копаю исходники, смотрю, где вместо fieldName подставляется headerName...

P.S. не исключено, что корни проблеммы одни, что описал drow в предыдущем топике

[Subst]

Итак...

Проблема в том, что lrdatadesignintf.cpp
в качестве названия поля берется headerName(). И это логично, поскольку в QAbstractItemModel это единственное свойство, определяющее текстовое обозначение столбца. Но нам от этого не легче...

Как вариант, для определения названия в report'е брать это же свойство, но, скажем, не c Qt::DisplayRole (по умолчанию), а с Qt::EditRole.
Ну и описать в мануале, что надо задавать два свойства для столбцов. Иначе будем сталкиваться с этой проблемой.

Вот код:

QString ModelToDataSource::columnNameByIndex(int columnIndex)
{
    if (isInvalid()) return "";
    return m_model->headerData(columnIndex,Qt::Horizontal).toString();  <----------------------------
}


Ну и, соответвенно, поправить смежные функции, такие как

int ModelToDataSource::columnIndexByName(QString name)

может, что-то еще, не копал пока дальше. Жду ответа и мнения от Алекса

[Subst]

Внес изменения, пересобрал, вроде работает

[Arin Alex]

Тоже поправлю Думаю только посадить на Qt::UserRole

[Subst]

Вариант.
Но есть один ньюанс. Если разработчику данный момент непринципиален, то в случае EditRole ему не нужно писать дополнительный код. А в случае UserRole придется.

EditRole=DisplayRole, если не переопределено явно, а UserRole=QVariant()

тут уж смотри, как удобней.

[Arin Alex]

Да в общем можно и EditRole использовать Сейчас поиграюсь Отпишусь.

[Subst]

Ну как бы маловероятно, что кому-то в процессе работы с программой надо будет редактировать название полей. Вроде как вотчина программиста. Так что EditRole тут вполне безовасно использовать. Разве что, какой-то конструктор Модели будет делаться

[Arin Alex]

Поигрался У меня получилось следующее :
setHeaderData() по умолчанию выставляет EditRole, а также устанавливает DisplayRole = EditRole.
если setHeaderData() не вызывается то EditRole = QVariant()
соответственно, для того, что бы разделить значения, все равно, надо вызывать setHeaderData() и для Qt::DisplayRole и для Qt::EditRole;
мне кажется, здесь у пользователей может возникнуть путаница А очевидных плюсов использования Qt::EditRole не вижу.
Возможно, я что-то упустил ?

[Arin Alex]

Посадил все-таки на Qt::UserRole Пушнул на гитхаб.

[Subst]

Да не, вроде, не упустил.
По сути разницы нету... Кусок кода для одной модели, заменить EditRole на USerRole - вроде не сложно
void TSpecialityModel::setHeaderNames()
 {
 setHeaderData(fieldIndex("id"),Qt::Horizontal,tr("ID"),Qt::DisplayRole);
 setHeaderData(fieldIndex("code"),Qt::Horizontal,tr("Code"),Qt::DisplayRole);
 setHeaderData(fieldIndex("speciality"),Qt::Horizontal,tr("Speciality"),Qt::DisplayRole);
 setHeaderData(fieldIndex("qualification_id"),Qt::Horizontal,tr("Qualification ID"),Qt::DisplayRole);
 setHeaderData(fieldIndex("qualification"),Qt::Horizontal,tr("Qualification"),Qt::DisplayRole);

 for (int i=0;i<record().count();i++)
  setHeaderData(i,Qt::Horizontal,record().fieldName(i),Qt::EditRole); <----------------------- тута
 return;
 }

Кстати, стоит наверное описать в хелпе, ситуация непрозрачная.