LimeReport Forum
General Category | Основное => Discussion | Обсуждение => Topic started by: Subst on April 13, 2016, 05:13:16 pm
-
У меня проблема следующая:
m_report->dataManager()->addModel(...) замечательно работает. Но до тех пор, пока я не сделаю локализацию, после этого
в списке полей отчета пропадает оригинально название поля, но появляется локализованное.
скажем поле city. В программе код setHeaderData(fieldIndex("city"),tr("City"));
Вот в limeReport и отображается как tr("City"), если в локализации Это "Город", то и будет Город. Крайне неудобно и похоже на баг (ну или фичу, если угодно :) ).
т.е. сделал отчет, локализовал программу - отчет заново творить. Сделал перевод на иной язык - отчет заново творить.
Копаю исходники, смотрю, где вместо fieldName подставляется headerName...
P.S. не исключено, что корни проблеммы одни, что описал drow в предыдущем топике
-
Итак...
Проблема в том, что 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)
может, что-то еще, не копал пока дальше. Жду ответа и мнения от Алекса
-
Внес изменения, пересобрал, вроде работает
-
Тоже поправлю :) Думаю только посадить на Qt::UserRole
-
Вариант.
Но есть один ньюанс. Если разработчику данный момент непринципиален, то в случае EditRole ему не нужно писать дополнительный код. А в случае UserRole придется.
EditRole=DisplayRole, если не переопределено явно, а UserRole=QVariant()
тут уж смотри, как удобней.
-
Да в общем можно и EditRole использовать :) Сейчас поиграюсь :) Отпишусь.
-
Ну как бы маловероятно, что кому-то в процессе работы с программой надо будет редактировать название полей. Вроде как вотчина программиста. Так что EditRole тут вполне безовасно использовать. Разве что, какой-то конструктор Модели будет делаться
-
Поигрался :) У меня получилось следующее :
setHeaderData() по умолчанию выставляет EditRole, а также устанавливает DisplayRole = EditRole.
если setHeaderData() не вызывается то EditRole = QVariant()
соответственно, для того, что бы разделить значения, все равно, надо вызывать setHeaderData() и для Qt::DisplayRole и для Qt::EditRole;
мне кажется, здесь у пользователей может возникнуть путаница :) А очевидных плюсов использования Qt::EditRole не вижу.
Возможно, я что-то упустил ?
-
Посадил все-таки на Qt::UserRole :) Пушнул на гитхаб.
-
Да не, вроде, не упустил.
По сути разницы нету... Кусок кода для одной модели, заменить EditRole на USerRole - вроде не сложно :D
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;
}
Кстати, стоит наверное описать в хелпе, ситуация непрозрачная.