General and Desktop

@SGaist Thanks for your reply will check in that way

@jdent I know: value.isNull()!!

@DeadComposer Switching to GCC 10 worked.

@ZNohre Such an error can appear when the same item delegate is used in multiple views.

For me the solution was : 1.Selecting MSVC compiler instead of MinGW. or 2. Forced Enabling clangd which was disabled due to my low ram. After that everything worked like charm

Try QPainterPath::simplified()

@SimonSchroeder Yeah I went with a custom scaling method and using fast transformation. When there are a lot of pixel drawn, I still have some doubled pixel (probably), but i cant notice it because its too small. However, when it is zoomed enough, it looks good. My method is really simple, but it's fast enough. To keep it simple, I compute the area I want to see and copy these pixels to a new buffer I give to QImage. Then I let FastTransformation do its job

@Pl45m4 Thank you so much. I created the chart in mainwindow as suggested. And also, I solved the click issue either.

Well, it works if I inherit from QOpenGLFunctions_4_5_Compatibility instead of QopenGLExtraFunctions along with QOpenGLWindow. I guess the render buffer needed gl functions in the former that is not present in the later.

First of all, the dirty solution: Call QApplication::processApplication repeatedly to process the update of the progress bar. But, actually don't do it! This solution is way too slow! For threads you have several options: There is the worker thread solution as already mentioned. You can also use QThread::create with a lambda. There is QMetaObject::invokeMethod which can place work inside an existing thread (just a plain QThread object on which run() has been called which starts the thread's event loop). And there is QtConcurrent::run (and its siblings). Handling threads directly comes with its pitfalls. 1) You need to make sure that the thread lives long enough (most of the time this means that you do not create the thread object on the stack). 2) If you have a function with a lot of work to be done and only place the middle part into a thread, the function will not wait for the results of the thread (otherwise it would be blocking the main event loop again and you would not see an update of the progress). 3) You cannot call any GUI functions from other threads. You can connect a signal from within your thread to the progress dialog that lives outside your thread and it works, but you cannot just call the functions of the progress dialog. There are workarounds like QMetaObject::invokeMethod to place calls to the progress dialog inside the GUI thread. I have written a small library because this was reoccuring in our project (https://github.com/SimonSchroeder/QtThreadHelper). With this library use workerThread(...) with a lambda to start some work in a separate thread and guiThread(...) with a lambda to place something inside the GUI thread. You can also just have a look at the implementation of guiThread to see how to place calls into the GUI thread. One other note: Do not update the progress dialog too often! We use QTime to start a timer (calling start()) before the loop and check for elapsed() inside the loop. Only if, for example, 50ms have passed we trigger an update of the progress dialog and call restart() on the timer. This helps if the loop is too fast.

@swjqq Please post code as text, not pictures. m_service and m_characteristic are not allocated in your thread.

@oohogwash said in starter project for visio list, drag drop, panel interface: the open source version looks like it is 9 yrs old now The Qt Graphics Framework is a part of all versions of Qt 5 and Qt 6 (widgets module, open source or commercial) right up to the latest of each: neither of which is 9 years old.

@hskoglund Yes. I also have MinGW installed separately on my computer so I could try quickly making another kit with those and see if it works. Edit: Changing the version of MinGW in the kit worked! I tried using regular MinGW 64-bit and that made it work perfectly. Thanks so much

@Blackzero said in how do you use threads in a very heavy loop process in one class and without using additional class objects?: yes gradually, So you need to have a instance var to memorize the current step. For each step you need to call the event loop, the idea in pseudo code void processNextStep() // must be defined as a slot { process current step if last step return current step++ update progressbar call slot processNextStep // see below } You have two ways to call the slot method 1- QMetaObject::invokeMethod in mode Qt::QueuedConnection 2- QTimer::singleShot((0) See the docs for more infos.

@Pl45m4 nope, I understood ;-) I wanted to know why additional letter was needed since it's not how QSyntaxHighlighter works as you correctly explained.

@jsulm yes xhost + 127.0.0.1 works to me. Thanks

@Christian-Ehrlicher Its working now. Thanks very much!

@AnneRanch Another one bites the dust. When you point one finger at what you find a put-down attitude, three fingers are pointing back at you. “Please translate this to English” is how you started this post with a put down, insinuating that our documentation isn’t written in proper English. At the same time you mix up slots with events. It’s ok, not to understand everything. But it’s hypocrite to blame others for things you allow yourself. Don’t do that, it’s not welcome. I will follow that up internally.