General and Desktop

@stvokr I wrote earlier @stvokr One thing: if you are saying you apply a color in code to style, that will be overridden/ignored if there is stylesheet rule applicable. Depends how you set the color of the listwidgetitem. So, yes, if you use QSS that will override setForeground() etc. You will need to stick with one or the other.

@JonB said in Single Click Event on Q: This is not a full application, just an extract. Presumably if "the application exits" on a click there is an error, and you get an error message somewhere. ?

@JonB I still think I am using wrong widget / signal. I can only position and click the mouse. I cannot highlight the text - the positioning of mouse overrides that.

tr is used for text translation. It's an old habit of mine to write my code so that translation can be implemented at anytime. As for your use case, just nuke your "tab" object and add text directly to your ui QTabWidget: ui->tabWidget->addTab(text, tr("Text Edit"));

@Emon-Haque From the bug report, I wouldn't worry about it, cross fingers it won't come up again.

@mpergand, yes subclassing is the way to go in my opinion too. So far Qt Widgets isn't that bad as I though it'd be. It's fast and looks like it doesn't use GPU at all.

Seems you are engaged in a loop. Run the debugger and when it's hang, interrupt the debugger to see the stack frame. [Edit] too late :)

Thanks a lot! That did the trick. Interesting! Wasn't aware of that difference.

@CEO yes but ODBC drivers are not installed by default so make sure you have them on the other laptop if you didn't install SQL server there. It might not be installed then.

@8Observer8 thank you. It's actually relevant information I missed.

@Caeden "You can't", at least so far as I know. Either you would have to re-create all the widgets etc. the other window shows, which is not a small task. You cannot "share"/"re-use" widgets across windows. Or, if it suits your purpose, you could dump one window to an image, like a "screenshot", and then show that in another window.

Just try it out

@mmikeinsantarosa Indeed, that is how Qt documentation lays out its methods. To reiterate something @Christian-Ehrlicher said. In Qt nomenclature: Methods ending in Event (showEvent(), mouseMoveEvent()) are not signals. Instead they are protected virtual methods. You must sub-class and override if you want to access them. Signals tend to be named as the past tense of something that has happened (clicked(), customContextMenuRequested()). You cannot override them. You can connect() to them, without needing to sub-class. And slots are just named as an action to be performed (show(), setDiabled()).

@eyllanesc is it possible for you to give me an idea about where to start? theory-wise?

@Publicnamer said in QString optimized out, causes segmentation fault: Anyone know why this might happen? It really does crash for me compiling with G++ and with clang. Yes, the code presented in the original post will crash for exactly the reason described by @mchinand. The result almost certainly will not change with compiler or optimization level, but might be more informative if compiled for debug. Here is your example, or something "virtually identical" to it: #include <QCoreApplication> #include <QString> #include <QVector> #include <QDebug> struct mystruct { QString s; int i; }; int main (int argc, char **argv) { QCoreApplication app(argc, argv); qDebug() << "Starting"; QVector<mystruct> v; // <<<< this vector has no members v[3].s = "abc"; v[3].i = 123; qDebug() << v[3].s << v[3].i; qDebug() << "Ending"; qDebug() << "Ending"; return 0; } Here is what happens when compiled for release (-O2 optimization, gcc version 9.3.0) chrisw@newton:/tmp/crash$ qmake -v QMake version 3.1 Using Qt version 5.12.8 in /usr/lib/x86_64-linux-gnu chrisw@newton:/tmp/crash$ qmake CONFIG+=release Info: creating stash file /tmp/crash/.qmake.stash chrisw@newton:/tmp/crash$ make g++ -c -pipe -O2 -Wall -W -D_REENTRANT -fPIC -DQT_DEPRECATED_WARNINGS -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -I. -I. -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -I. -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o main.o main.cpp g++ -Wl,-O1 -o crash main.o /usr/lib/x86_64-linux-gnu/libQt5Gui.so /usr/lib/x86_64-linux-gnu/libQt5Core.so /usr/lib/x86_64-linux-gnu/libGL.so -lpthread chrisw@newton:/tmp/crash$ ./crash Starting Segmentation fault (core dumped) ... and for debug (no optimization at all, and debug symbols): chrisw@newton:/tmp/crash$ make distclean rm -f moc_predefs.h rm -f main.o rm -f *~ core *.core rm -f crash rm -f .qmake.stash rm -f Makefile chrisw@newton:/tmp/crash$ qmake CONFIG+=debug Info: creating stash file /tmp/crash/.qmake.stash chrisw@newton:/tmp/crash$ make g++ -c -pipe -g -Wall -W -D_REENTRANT -fPIC -DQT_DEPRECATED_WARNINGS -DQT_GUI_LIB -DQT_CORE_LIB -I. -I. -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -I. -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o main.o main.cpp g++ -o crash main.o /usr/lib/x86_64-linux-gnu/libQt5Gui.so /usr/lib/x86_64-linux-gnu/libQt5Core.so /usr/lib/x86_64-linux-gnu/libGL.so -lpthread chrisw@newton:/tmp/crash$ ./crash Starting ASSERT failure in QVector<T>::operator[]: "index out of range", file /usr/include/x86_64-linux-gnu/qt5/QtCore/qvector.h, line 437 Aborted (core dumped) With/without optimization, same result, ergo not optimization induced. Debug version tells you exactly why it crashed, if only you looked. gdb, on a debug version, will tell you which line of your code triggered it: chrisw@newton:/tmp/crash$ gdb ./crash GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2 ... Reading symbols from ./crash... (gdb) run Starting program: /tmp/crash/crash [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Starting ASSERT failure in QVector<T>::operator[]: "index out of range", file /usr/include/x86_64-linux-gnu/qt5/QtCore/qvector.h, line 437 Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007ffff7694859 in __GI_abort () at abort.c:79 #2 0x00007ffff7ae3aad in QMessageLogger::fatal(char const*, ...) const () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #3 0x00007ffff7ae2f46 in qt_assert_x(char const*, char const*, char const*, int) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x0000555555555d85 in QVector<mystruct>::operator[] (this=0x7fffffffdf60, i=3) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qvector.h:437 #5 0x0000555555555453 in main (argc=1, argv=0x7fffffffe0b8) at main.cpp:16 (gdb) If you correct your erroneous code to, for example: #include <QCoreApplication> #include <QString> #include <QVector> #include <QDebug> struct mystruct { mystruct(): s(), i(0) { } // <<<< a constructor so the int is never undefined QString s; int i; }; int main (int argc, char **argv) { QCoreApplication app(argc, argv); qDebug() << "Starting"; QVector<mystruct> v(4); // <<<< this vector actually has 4 default constructed members v[3].s = "abc"; v[3].i = 123; qDebug() << v[3].s << v[3].i; qDebug() << "Ending"; return 0; } Then, oddly, it does not crash: chrisw@newton:/tmp/crash$ make g++ -c -pipe -O2 -Wall -W -D_REENTRANT -fPIC -DQT_DEPRECATED_WARNINGS -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -I. -I. -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -I. -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o main.o main.cpp g++ -Wl,-O1 -o crash main.o /usr/lib/x86_64-linux-gnu/libQt5Gui.so /usr/lib/x86_64-linux-gnu/libQt5Core.so /usr/lib/x86_64-linux-gnu/libGL.so -lpthread chrisw@newton:/tmp/crash$ ./crash Starting "abc" 123 Ending

@SGaist, Informational

Hi Christian, thank you very much for your attention and your question! I just wanted to explain, why result should change between second and third test and not between first and second test. ... when I discovered my error! I connected the wrong function to signals. Fixed that and now the tests pass :) Thanks!

@jeremy_k The input system is dodgy...

Hi @mpergand, it works perfectly, thanks.