Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

QTableWidget has blank cells after I set their strings



  • I do this:

    static const char *mystrings[50000] = { ... };
    table->clearContents();
    table->model()->insertRows(0, 50000);
    for (int i=0; i < 50000; i++) {
      QModelIndex index = table->model()->index(i, 0);
      table->model()->setData(index, mystrings[i], Qt::EditRole);
    }
    

    For some reason all the cells are empty. What could be the cause?
    At other times, some of the cells have data and some are empty.



  • @Publicnamer
    Did you really type 50,000 strings into that source file?

    Try making the array be QStrings, any difference?

    If the contents seem to vary, print out mystrings[i] each time you add it.

    See what the behaviour is if you use QTableWidget methods like setRowCount() and setItem() with a QTableWidgetItem.



  • @JonB Yes I really do have 50,000 strings, but not there, they are in another file.
    However I have found a way to fix the issue. (I didn't try QStrings alas.)

    static const char *mystrings[50000] = { ... };
    table->clearContents();
    table->setRowCount(0);
    table->model()->insertRows(0, 50000);
    for (int i=0; i < 50000; i++) {
    table->model()->setItem (row, 0, new QTableWidgetItem(mystrings[i]));
    }

    I'm assuming that the clearContents and/or setRowCount call is deallocating any QTableWidgetItem objects that were previously allocated. If not, I'll need to update that.



  • @Publicnamer
    All good. Yes QTableWidget will take care of deallocations.

    I believe your setData() way would have worked if you had gone

    table->model()->setData(index, QString(mystrings[i]), Qt::EditRole);
    


  • @JonB Honestly I've had bad luck using QString, so I avoid it. I've seen really strange bugs, like malloc complaining its data was corrupted, just because I used QString.



  • @Publicnamer
    QString should never deliver such, unless you do some horrible things to it. Getting "bad luck" in the code you write is a new one on me :)

    Meanwhile your attempt to store char *s via setData() has led to what you describe as "inconsistencies". Your QTableWidgetItem(mystrings[i]) will store your char * as a QString, and that apparently does work for you. Anyway, since that seems to be working that is fine.



  • @JonB "Should never" is a promise, but QString doesn't live up to it. Even with very simple and safe uses of QString I've seen such bugs. It's easy to blame the user but the responsibility lies with Qt's developers to test it properly. I could say the same for QTableWidget.



  • @Publicnamer
    I have seen absolutely no evidence for such "bugs" in QString, and certianly not if it is used "simple and safe", nor that it has not been tested properly. It has been used for years by thousands of programmers.

    Instead of just casting aspersions around, why don't you offer just one code example which illustrates your claim? I am totally confident it will reveal a shortcoming in your code, not that of Qt.



  • @JonB If I encounter it again I will do so. Unlike some people, I don't attach my ego to my code, and nor should you. I've seen appalling issues with QString and some other Qt code, but sure if it was my mistake I'll own it. The problem with programmers these days is that they do insist there are no bugs (without evidence), they assume real testing is happening when it isn't, which leads directly to really bad bugs. It's called cognitive dissonance: The message you don't want to hear leads to denials rather than reflection.


  • Lifetime Qt Champion

    @Publicnamer said in QTableWidget has blank cells after I set their strings:

    If I encounter it again I will do so.

    You told us some hours ago that there are bugs inside QString and your code you showed us triggers one of them. Now you tell us you can't reproduce it anymore?

    If you have a bug, show us the code. If not don't spread FUD.



  • @Publicnamer
    I look forward to your future illustration of such fundamental bugs in QString.

    The problem with programmers these days is that they do insist there are no bugs (without evidence),

    I don't agree with your sentiment here. Rather I find the problem with (some) programmers is that they are too quick to blame their tools --- toolkit, Qt, whatever --- when they should reflect on how widely used it is among other people and it is their own code they should examine instead. Speaking at least from experience on this forum I know just how many people come say "there is a bug in Qt" when their own code is faulty. Lots & lots of times....


Log in to reply