General and Desktop

@closer_ex They added a lot of highly expensive Q_ASSERT-statements sometime in Qt 5. That might be the cause of high CPU usage. EDIT: You can verify that by defining your own Q_ASSERT and Q_ASSERT_X macros before including the first Qt header file.

I fixed this by setting QFont font = this->font(); to ui->appName->font(); in case anyone comes across this.

@Christian-Ehrlicher Thanks for tracking that down. Hope Qt gets it fixed soon.

@Christian-Ehrlicher Ohhhhh! It works! I replaced all the function malloc() in my code, then the output of VLD went back to a normal value. THANKS A LOT!!!

@eyllanesc the problem was my Arduino. I simplified it just to test and based on your suggestion and now it is working properly even at 500K baud: Arduino code: char buffer[16]; void process(); void setup() { Serial.begin(500000); } void loop() { process(); } void process() { while (Serial.available() > 1) { Serial.readBytesUntil('\n', buffer, 16); Serial.println(buffer); } }

@CJha said in Main GUI thread stops when worker thread is invoked using Qt::QueuedConnection: I thought if I put the priority as QThread::LowPriority for one instance and QThread::HighPriority for the other then Qt will make sure that one with higher priority gets the resources whenever it requires regardless of how long the threads with lower priority are waiting? If this is not the situation then why do we have different priorities in the first place? This is not Qt-specific. On a multitasking system the priority of process or thread determines the timeslices it gets from the OS's scheduler. However, there are so many cores on a system, you can't get performance out of nothing. That's why if you're going to crunch numbers, you want to have a number of threads equal to the number of cores, so each thread runs on its own core as much of the time as possible without being interrupted. Having more threads than cores, contrary to (the layman) popular belief, doesn't produce better performance, it can get you some latency benefit if the cores are not busy, otherwise it's an overhead for the scheduler to slice and rebalance the time slots. That's why you have priorities - to "hijack" latency from other threads/processes running on that system, but again this doesn't mean your code is going to be running faster. @CJha said in Main GUI thread stops when worker thread is invoked using Qt::QueuedConnection: Most of the people on forums and blogs suggest subclassing QObject and use moveToThread() instead of subclassing QThread and implementing its run method, why do you suggest differently? Is there a catch? Yes, that's correct. For the general case this is best. If you want to squeeze out the most of the hardware however you're going to want to remove the pesky overhead that comes with this. That's "the catch" - having/choosing the correct tool for the job at hand. Never heard of TS queue, I will try to learn about it. That's a "thread-safe queue" so you don't get the wrong idea.

Hi, From the QBluetoothTransferManager::put documentation: If the platform does not support the Object Push profile, this function will return 0.

@jsulm Thanks. I have fixed it. I deleted 'static' from the declaration of my QPointF array. So, rather than have: static const QPointF points [3] = { ... } , I have: const QPointF points [3] = { ...}. Thanks everyone.

@SGaist thanks for your answers. Finally, I found the solution. I didn't use the right handle for register solution.

Hi Well, I think you set a fixed size on the spacer and that will not work when resizing the window. What you can do is to change the layout with the QTableViews to a Gridlayout. ( right-click it in the right side tree view and use the Layout menu to change it) Then move the buttons inside the grid layout with the Views. (delete the old layout where buttons were as we dont need it) Then on each button, right-click and change layout alignment to "TOP" [image: DLwTNq.png] and it will resize like this. I hope its what you want :) [image: drop4.gif]

@jbbb said in Program crashes when global variable included.: any idea what this means? Take a look at the stacktrace to see where it comes from (as already said in my first post). I would guess the this pointer is a nullptr.

I reinstall conda and after its work

Hi, there is https://doc.qt.io/qt-5/qfiledialog.html#setSidebarUrls, is that what you want?

@Christian-Ehrlicher said in Issues with qtDir::exist: is by default set to the build dir Ohhhh! I had not noticed that! Partly because when I started out on Qt I was using Python/PyQt5/PyCharm, which obviously does not have a "build directory" nor a .pro file. When I changed over to C++ + Creator I just never looked for this.....

@Christian-Ehrlicher said in QTCP threading ... again: There is no conflict because now both operations are done in the same thread. Oh sure, of course... Thank you very much for your help!