Switch from 1.3.x to 1.6.8, weird behaviour into slotGetCallbackData, anormal call of the SLOT

[lchauvinQt]

Hi, I'm switching to Qt6 into one of my project and I updated my LimeReport version to 1.6.8.
I encountered serious difficults to port my reports due to a strange behavious into the call of slotGetCallbackData on SubDetailDataBand .
On most part of my reports I'm using DataBand and SubDetailDataBand, the first for the tables and the second for the rows of the table. I do make my connection into a parent object and childrens classes does inherit from the connection and override the slots.
For me the normal behaviour for the SubDetailDataBand is to be called like "Row_cout" x "column_count" but it does no longer happen this way. In the example inside the documentation :

void MainWindow::slotGetCallbackData(LimeReport::CallbackInfo info, QVariant &data) { if (!m_customers) return; prepareData(m_customers, info, data); }

The problem can't really occurs because we left the process before the count get over the max supposed count.
I found a workaround into my code to prevent to go to far into iterations. :

void BalanceComptesDetailles::slotChangePosDetail(const LimeReport::CallbackInfo::ChangePosType &type, bool &result) { m_isDataToProcess = true; }

and Into my CallBackSlot :

void BalanceComptesDetailles::slotSimpleCallbackGetDataDetail(const LimeReport::CallbackInfo &info, QVariant &data) { switch (info.dataType) { case LimeReport::CallbackInfo::ColumnCount: data = tableHead->size(); break; case LimeReport::CallbackInfo::RowCount: data = limite2; break; case LimeReport::CallbackInfo::IsEmpty: data = false; break; case LimeReport::CallbackInfo::ColumnHeaderData: data = tableHead->at(info.index); break; case LimeReport::CallbackInfo::ColumnData: if( m_isDataToProcess ) { if ( info.columnName == tableHead->at( tableHead->count()-1)) m_isDataToProcess = false; } .... some code ... break; }
I did only noticed that behavious into SubDetailDataBand.

[fralx]

Hi,

"Row_cout" x "column_count"

LimeReport makes no guarantees about how many times this slot will be called and for which colum and therefore you should not rely on such assumptions. You can make cache for row values to prevent multiple preparing process