General and Desktop

If you chose a CMake project, a CMakeLists.txt file will be used. You have to choose qmake as build system to get a .pro file.

@Pablo-J-Rogina i changed the class name aswell to match :) Socket class socket object

@JonB I have also tried with setFilterFixedString and the proxymodel still doesn't filter. I don't need to set filterRole as it is display role be default. As I understand the docs, I shouldn't need to subclass the proxymodel for such a simple use case. It should be working out of the box. You are right I misspelled. It should be fifth column but the code is correct. Let me share a screen shot of the table I'm trying to filter.! [image: d56681df-7ee5-4aa8-ae7c-1040851de04c.png]

@kuzulis said in QSerialPort readAll() does not work with 5.14.0 anymore PS: And yes, you don't need in QThread::msleep(3), because it has not sense (because the sleeping already does by waitForXXX() methods). Ah, ok. I guess bool com::waitForReady(int timeout) { waitForReadyRead(1); QElapsedTimer elapsed; elapsed.start(); while (bytesAvailable() == 0 && elapsed.elapsed() < timeout) { waitForReadyRead(1); } if (elapsed.elapsed() < timeout) { return true; } return false; } is the "correct" solution then. Update: Just for the sake of completeness, here is the patch for my program: https://github.com/BrillouinMicroscopy/BrillouinAcquisition/pull/135

@JonB You were right about being surprised. Because it wasn't returning Qt::ItemIsAutoTristate. I'm overriding the setData()-function in that model as well and apparently the issue came from handling the checked-state in there. I'm not yet sure how this resulted in this behavior. So thank you, the issue was NOT with the flags.

I got it fixed, thanks to @Christian-Ehrlicher! I almost did not try your suggestion because I thought I knew very well where the warning comes from. But it turned out that I had missed a setQuery() call that was lacking its second parameter (the database connection to use).

@mirro What is your question/problem? That link shows a number of examples.

Hi @Christian-Ehrlicher , Thank you for your comment. Perfectly understood. Have a nice day, Davide

@simone-malvezzi Always a good idea to state your Qt version when asking a question like this! :)

@terryGGG It doesn't crash every time, the crash possibility may lower than 0.1%. I don't think anyone will be able to solve this for you from what you show. And you do not say what version of Qt you are using, which might be relevant. Write yourself a standalone program, as minimal as possible [~20 lines?], which just does your code, 10,000 times in a loop. Make the command something simple & harmless, say dir or echo hello. Does it crash? Does it matter what the command is? If you do get a crash: get rid of both cmd->waitForStarted(); cmd->waitForFinished(-1); and replace with the QProcess signal/slots equivalent, so no waitFor...() calls, which can be "dodgy", especially potentially under Windows. Does that crash?

@Kris-Revi said in QtWebSockets and custom Signals: Socket is MySocket constructor (MySocket is a class) Sorry, but "Socket is MySocket constructor" just does not mean anything. Nor do I know what your earlier "i've put Socket(this) under the init of MainWindow" means. If Socket is indeed a class, then you cannot write connect(Socket, ...) in any situation. connect() connects the signal of one object/instance to a slot of another object/instance. Not classes. I think you are wanting to achieve the following: You have a class MySocket. It is a QObject, so it can use signals/slots. It has a member QWebSocket m_webSocket;. So it contains/encapsulates a QWebSocket, but it is not a QWebSocket itself. You define a custom signal whenConnected(), which you want emitted when the socket is connected. You define a custom slot in MainWindow, to connect to that signal. So... Inside MySocket you want to connect m_webSocket's connected signal to a slot, also inside MySocket, which goes emit whenConnected(), to raise/emit that signal to the outside world. And inside MainWindow you want to define a slot which you connect there to the MySocket::whenConnected() signal. Is that right?

@SGaist yes, hovering will be okay too. I just didn't think that constant mouse tracking is such a problem.

For anyone also having this problem, I've discovered the cause of the issue I observed, as well as a workaround. The completion prefix can have a stale value even if the text entry field is cleared, and this prefix can prevent any completion matches from being found, causing the size hint to return 0. To get around this, manually clear the completion prefix before querying for the size hint. If the text entry field isn't being cleared as well at the same time, the prefix can be stored before it is cleared and restored after the size hint is retrieved, keeping the prefix and entered text synchonised. QObject::connect(&button, &QPushButton::clicked, [&completerModel, secondStringList, &completer]() { QString cachedPrefix = completer.completionPrefix(); completer.setCompletionPrefix(""); completerModel.setStringList(secondStringList); completer.popup()->setFixedWidth(completer.popup()->sizeHintForColumn(0)); completer.setCompletionPrefix(cachedPrefix); });

@Pl45m4 In 99% of all cases, there actually IS a similar question and you can find the answer on your own. The thing I've often found is that, when being new, the hardest part of solving a problem is actually knowing how to frame your question. If you knew exactly what to ask, then a lot of the times you'd already have your answer. If not, a simple google search would give it to you. I get that people get tired of the same questions over and over, but when you're a noob, sometimes it takes an actual human being who can hear what you're saying and get the actual question out of it even if google fails to do so.