General and Desktop

It works fine for me with Qt6.9.1 with the windows11 style: int main(int argc, char *argv[]) { QApplication app(argc, argv); QTableWidget tw; tw.setRowCount(5); tw.setColumnCount(1); auto item = new QTableWidgetItem("Item"); tw.setItem(0, 0, item); QTimer::singleShot(2000, &tw, [&]() { tw.item(0, 0)->setCheckState(Qt::Checked); }); tw.show(); return app.exec(); } Please provide a minimal, compilable example of your problem.

@SuhasKrishanamurthy hi, Since you marked your thread as solved, can you share what you did / change to fix the situation ? It might help other people.

@SGaist Thanks for your help. I already have access to QtWebKit. Its there in my Qt installation. Crash is intermittent so inferring what content triggers crash might not be easy. I am trying to figure out again if I can instead use QWebEngine. Lets see, hopefully I wont have to use QtWebKit.

hi @aha_1980 Thanks for the reply. Before I got it, I'd just started doing a thing where I was counting the bytes read back in and only starting to take any notice of the data when I had read in the number of bytes sent out, so I was along the right lines. It's a bit of a pain, but with what you're saying about bytesReceived being called not being a guarantee it's gone out on the line, I guess it's not going to help anyway. For a while I have been thinking I need to get to grips with QSerialPort but as I know qextserialport so well I've been lazy. I do know that in v6 qext... is no longer available. Thanks for the post.

@AndyBrice said in Cache locality and QString: Ok, thanks for the feedback. It looks like there is no straightforward ways to improve performance, while keeping the flexibility I need. Correct. The optimization will come at a cost of working only when on a predictable subset of real world data. Because you've stated that you need a generalizaed solution, the optmization tricks wont work reliably. If you can assign hard limitations to your dataset...THEN you can consider what kinds of optimiztions make sense.

@yonizaf You should not create a new ticket. You commented in the existing, let's see whether this triggers any actions :-)

Code: #include <QCoreApplication> #include <QLocale> #include <QDate> #include <QtDebug> int main(int argc, char* argv[]) { QCoreApplication a(argc, argv); QLocale locale1(QLocale::German, QLocale::Germany); for (int m = 1; m <= 3; m++) { QDate date1(2025, m, 1); qDebug() << "locale1=" << locale1 << " date1=" << date1 << "locale1.toString( date1, \"MMMM\" )=" << locale1.toString(date1, "MMMM"); } const auto locales = QLocale::matchingLocales(QLocale::AnyLanguage, QLocale::AnyScript, QLocale::AnyCountry); for (const QLocale& locale2 : locales) { if (locale2.country() == QLocale::Germany && locale2.language() == QLocale::German) { qDebug() << "locale1 == locale2 =" << ( locale1 == locale2 ); for (int m = 1; m <= 3; m++) { QDate date2(2025, m, 1); qDebug() << "locale2=" << locale2 << " date2=" << date2 << "locale2.toString( date2, \"MMMM\" )=" << locale2.toString(date2, "MMMM"); } } } return 0; } Results: Qt 5.15.18/MSVC2019/Windows: Qt 5.15.18/XCode/macOS: locale1= QLocale(German, Latin, Germany) date1= QDate("2025-01-01") locale1.toString( date1, "MMMM" )= "Januar" locale1= QLocale(German, Latin, Germany) date1= QDate("2025-02-01") locale1.toString( date1, "MMMM" )= "Februar" locale1= QLocale(German, Latin, Germany) date1= QDate("2025-03-01") locale1.toString( date1, "MMMM" )= "März" locale1 == locale2 = true locale2= QLocale(German, Latin, Germany) date2= QDate("2025-01-01") locale2.toString( date2, "MMMM" )= "January" locale2= QLocale(German, Latin, Germany) date2= QDate("2025-02-01") locale2.toString( date2, "MMMM" )= "February" locale2= QLocale(German, Latin, Germany) date2= QDate("2025-03-01") locale2.toString( date2, "MMMM" )= "March" ^^^Month is incorrect for locale2^^^ Qt 6.7.3/MSVC2019/Windows: Qt 6.7.3/XCode/macOS: locale1= QLocale(German, Latin, Germany) date1= QDate("2025-01-01") locale1.toString( date1, "MMMM" )= "Januar" locale1= QLocale(German, Latin, Germany) date1= QDate("2025-02-01") locale1.toString( date1, "MMMM" )= "Februar" locale1= QLocale(German, Latin, Germany) date1= QDate("2025-03-01") locale1.toString( date1, "MMMM" )= "März" locale1 == locale2 = true locale2= QLocale(German, Latin, Germany) date2= QDate("2025-01-01") locale2.toString( date2, "MMMM" )= "Januar" locale2= QLocale(German, Latin, Germany) date2= QDate("2025-02-01") locale2.toString( date2, "MMMM" )= "Februar" locale2= QLocale(German, Latin, Germany) date2= QDate("2025-03-01") locale2.toString( date2, "MMMM" )= "März" ^^^ Month is as expected^^^ So the localised month is wrong (but only inside the loop) for Qt 5.15.18. Weirdly, day of week ("ddd" or "dddd") is correct in both cases. I can work around it, but it is a very odd bug.

@Taytoo https://forum.qt.io/topic/136174/printing-a-simple-pdf

Qt 5.6 is even more outdated than Qt 5.15. Please try a newer version of Qt!

@SGaist Thanks, i'll check it out!

@dabble53 Simple: Your point is in parent coordinates. And parent is the centralWidget to which your widget is located at 40,40... exactly the values to pass to it. So how do you print these numbers?

QFileSystemModel loads its content asynchronously so at some point it likely has file handles opened to do its work which could explain what you are experiencing.

Thanks. Now I think I manage to do that.

Hello All, It was my environment which is creating the miss behavior of moc. My building tools were pointing to the wrong version of VSVC (MSVC 2019). I corrected this, and all worked fine. "My Culpa" Sincerely.

My project path contains non-ASCII characters, which might cause this macro not to work.

I solved the problem for my machine. I did change 2 things at the same time: The one that I think solved it was disabling the llvm use flag for mesa. I also enabled the z3 flag (as it was also mentoined here) for llvm. Maybe if I have time I'll see which one causes the bug, but for now it works and the long queue of print jobs that need printing can finally be done! Gentoo Linux users have a solution how to tackle this and if newer versions of Ubuntu or other Linux distro's have this issue, then at least there is some information for a solution.

@osirisgothra hi, I would say that modifying ld.so.conf.d to point to a non system Qt is the wrong way to do that. Either you have your distribution provided Qt that is installed or you use a wrapper script that will modify LD_LIBRARY_PATH for your application to find the dependencies you provide along said application.

Please format your code!