QTableWidgetItem::setTooltip() once works, other time doesn't

Basically, the code is:

Code:

---

for( int idx = 0; idx < count; idx ++ ) {
        log_entry entry = lgit_->log().entry( idx );
        QTableWidgetItem *item1 = new QTableWidgetItem( QString::fromStdString( entry.sha ) );
        QTableWidgetItem *item2 = new QTableWidgetItem( QString::fromStdString( entry.author ) );
        QTableWidgetItem *item3 = new QTableWidgetItem( QString::fromStdString( entry.message ) );
 
        item1->setTextAlignment( Qt::AlignLeft | Qt::AlignVCenter );
        item2->setTextAlignment( Qt::AlignLeft | Qt::AlignVCenter );
        item3->setTextAlignment( Qt::AlignLeft | Qt::AlignVCenter );
 
        QString summary = QString::fromStdString( entry.diff_data_summary_html() );
        item1->setToolTip( summary );
        item2->setToolTip( summary );
        item3->setToolTip( summary );
 
        int row = ui->tableWidget->rowCount();
        ui->tableWidget->insertRow(row);
 
        ui->tableWidget->setItem( row, 0, item1 );
        ui->tableWidget->setItem( row, 1, item2 );
        ui->tableWidget->setItem( row, 2, item3 );
}

---

Nothing special, I guess. I've verified that `summary` isn't empty. The code in wider context.

I call this code when log data is already available: thus, the table is filled with items right after creation. Then the tooltips work. However, when I start the dialog when log data isn't available, and wait for user to press "Fetch*" button to download the log data, then the tooltips doesn't appear. I really verified that the `summary` variable isn't empty. I even did `qDebug() << item1->toolTip();`, and it showed text. Has anyone any ideas what can be wrong? Apparently something slight is changed in the second execution path. What could I invoke as a workaround? Or to debug this?

Quote:

---

Apparently something slight is changed in the second execution path.

---

Since all you've presented is a fragment of code floating out there somewhere in the universe, it's hard to know what the first execution path is, much less the second. The code as it stands looks fine. How you're invoking it makes all the difference, and since you haven't provided that there's no way for us to help you identify what's wrong.

Quote:

---

Originally Posted by d_stranz

How you're invoking it makes all the difference, and since you haven't provided that there's no way for us to help you identify what's wrong.

---

I was counting on some expertise here, some tips that could e.g. help reveal the problem. The execution path is contained in the function that I linked, it is almost all contained because I'm just creating QTableWidgetItems, which means there is nothing accumulated in them before second execution path. It is possible that QTableWidget accumulates something, though, except it's an absurd that it can have something to do with separate objects – the items. I can add some code and paste results here, maybe this is a way to track this down? In the code that I linked, one has to only grep for "QTableWidget" to see what's done with the table, and the class isn't that large.

Quote:

---

In the code that I linked

---

Sorry, for some reason my browser doesn't highlight URL links on this forum, so I didn't see the link to the full code.

In the "code in wider context" I see only one place where PullDialog:: logOfTip() is called (in reset()), but reset() is called from numerous places. The logic is pretty convoluted so it is a bit hard to follow.

I can suggest several things:

- call QTableWidget::clear() or QTableWidget::clearContents() instead of QTableWidget::setRowCount() when you want to empty out the table. You have calls to setRowCount() in several places, like switchTableToLog(), switchTableToNotifications(), logOfTip(), and maybe more.

- in logOfTip(), since you already know the row count before entering the for() loop, set the row count to that instead of adding a new row each time through the loop. Simply call QTableWidget::setItem().

As I said, the code in logOfTip() that fills the table looks fine (but maybe is not as efficient as it could be).

Is it possible that whatever the rest of your program is doing locks up the GUI so events are not getting processed?