1

Topic: QTableWidget - Brakes at title formation

All greetings. Help please, to find a problem candidate solution. I form title QTableWidget _ui.calcDataView-> setColumnCount (daysCnt*2 + 1); QTableWidgetItem * item = new QTableWidgetItem ("ID"); _ui.calcDataView->setHorizontalHeaderItem (0, item); _ui.calcDataView-> hideColumn (0); QDate dt = _reportParameters-> from ().date (); for (int i=1; i <=daysCnt*2; i ++) {QString str = QString:: fromUtf8 ("Arrival %1").arg (dt.toString ("dd. MM")); QTableWidgetItem * item = new QTableWidgetItem (str); _ui.calcDataView->setHorizontalHeaderItem (i, item); QApplication:: processEvents (); i ++; str = QString:: fromUtf8 ("Leaving %1").arg (dt.toString ("dd. MM")); item = new QTableWidgetItem (str); _ui.calcDataView->setHorizontalHeaderItem (i, item); dt = dt.addDays (1);} At big kol-ve columns (for example more than 300), on title formation leaves more minutes. Time  paste operation _ui.calcDataView->setHorizontalHeaderItem (i, item); Still there are variants - faster? Through _ui.calcDataView->setHorizontalHeaderLabels (headers); tried - still !!!

2

Re: QTableWidget - Brakes at title formation

Hello, Demon051, you wrote: It is necessary to refuse from QTableWidget and to pass on QTableView.

3

Re: QTableWidget - Brakes at title formation

Hello, Qt-Coder, you wrote: QC> Hello, Demon051, you wrote: QC> It is necessary to refuse from QTableWidget and to pass on QTableView. Unfortunately already late... The Project at a stage of end and here at check on great volumes it also floated. On given  the heap of all is fastened and now it is necessary to get out somehow. I correctly understand, what passage on QTableView leads to necessity of creation of any models etc.? Or there it is possible as simply as with QTableWidget, but will faster work?

4

Re: QTableWidget - Brakes at title formation

Hello, Demon051, you wrote: D> I correctly understand, what passage on QTableView leads to necessity of creation of any models etc.? D> or there it is possible as simply as with QTableWidget, but will faster work? Yes the model is necessary. In it are described both titles and the data. QTableWidget it  over QTableView. The main brakes by operation with QTableWidgetItem. By the way, an insertion in cycle QApplication:: processEvents (); never accelerates operation. On the contrary the operation cycle distracts on handling of messages, including on . Try to remove it to begin with.

5

Re: QTableWidget - Brakes at title formation

Hello, Qt-Coder, you wrote: QC>... QC> By the way, an insertion in cycle QApplication:: processEvents (); never accelerates operation. On the contrary the operation cycle distracts on handling of messages, including on . Try to remove it to begin with. As a variant if there is no time for the normal decision - it is possible to pull it, for example, once on each 30-100 iterations of a cycle. A step to pick up empirically. Concerning models and high-speed performance - actually nobody forbids to form model in a separate flow, and then for 1 operation to substitute model already in GUI a flow. QStandardItem is not successor QObject/QWidget. Many for some reason about it forget.

6

Re: QTableWidget - Brakes at title formation

Hello, SaZ, you wrote: SaZ> Hello, Qt-Coder, you wrote: QC>>... QC>> By the way, an insertion in cycle QApplication:: processEvents (); never accelerates operation. On the contrary the operation cycle distracts on handling of messages, including on . Try to remove it to begin with. SaZ> as a variant if there is no time for the normal decision - it is possible to pull it, for example, once on each 30-100 iterations of a cycle. A step to pick up empirically. SaZ> concerning models and high-speed performance - actually nobody forbids to form model in a separate flow, and then for 1 operation to substitute model already in GUI a flow. QStandardItem is not successor QObject/QWidget. Many for some reason about it forget. There were here such "crutches" on this subject _ui.calcDataView-> model ()-> blockSignals (true); _ui.calcDataView-> blockSignals (true);....... _ui.calcDataView-> model ()-> blockSignals (false); _ui.calcDataView-> blockSignals (false); To filling of title of the table are applied on hurrah - flies as the rocket

7

Re: QTableWidget - Brakes at title formation

Hello, Demon051, you wrote: D> there were here such "crutches" on this subject D> D> _ui.calcDataView-> model ()-> blockSignals (true); D> _ui.calcDataView-> blockSignals (true); D>....... D> _ui.calcDataView-> model ()-> blockSignals (false); D> _ui.calcDataView-> blockSignals (false); D> D> to filling of title of the table are applied on hurrah - flies as the rocket So-so. I would advise to make in the end of this all emit _ui.calcDataView-> model ()-> dataChanged (QModelIndex (), QModelIndex ()); to update contents. And that on some visual subjects can not  a content. .. With blockSignals be ready to casual falling, if the user  a mouse in  in the course of an update. To reduce risks, but not to remove them on 100 % it is possible   for the period of update. And as to forbid change of the size of a window on which lies . In general, we such crutches explicitly forbade at themselves. ... processEvents it is better to throw out generally from a cycle.