General and Desktop

The default path of resources with qt_add_qml_module should now be qrc:/qt/qml/<module name>. When in doubt you can use QDirIterator to recursively iterate over your qrc: folder to see what's in it. Using GammaRay is also a solution.

@Pl45m4 My last personal observation. Overloads are so easily coded, I always: Stick in without qOverload() and see if compiler/code model tells you overload needed. 99% not, 1%... ...Look up desired overload in docs and put into qOverload<>(). If compiler did not complain it would be harder, but it does.... #2 takes a few seconds. So I don't get the problem.

@IBM1401 Your problem is a bug in Qt 6.8.0 (or CMake).

One final update on this as I have since realised that QT_QUICK_BACKEND=software alone was not sufficient on Linux. I had to set both that and the offscreen plugin to get it working.

Yes, specifically C:\Users\amonra\Documents\GitHub\DSS\x64\Debug is the debug build output folder and that's where all the files in question are - either placed there by building my code, or by windeployqt (for the Qt dlls). I just checked and (at least) the OpenGL dlls in the debug directory were back level compared to the Qt 6.8.0 installation while the release directory had the correct ones. I manually deleted everything from the build output dirs and re-ran the build, after which of course it worked as I expected. How/why there were some back level dlls in the Debug directory ????

Thank you, that's set my mind at ease - all that stuff has been cleaned out with on small exception which is handled without needing those pre-processor settings.

@jsulm said in On other computers, the release version cannot use qtvirtualikeyboard: @houyawei said in On other computers, the release version cannot use qtvirtualikeyboard: But on other computers, Win7 and Win10, the keyboard cannot jump out Then probably not all dependencies are there. Does the debug build work? I solved the problem, D: \ Qt \ 5.15.2 \ mingw81_32 \ bin \ Qt5VirtualKeyboarddll also needs to be copied over https://blog.csdn.net/u011738895/article/details/143363147?spm=1001.2014.3001.5502

Then you should ask the Qt support for help. I would guess the development package for QtRPC is missing somehow.

@IgKh Thanks for the detailed information! I'm gonna just use the normal update() for now and maybe if I feel like hyper optimizing I'll look into setting up regions for the most intensive parts. Again, thank you so much!

@JoeCFD I've a semilar problem ... these appear afte open one or two modal messages .... stat app no problem at all ... but after start one or two modal messagesbox become diffucult press button or have focus with touch screen ... but with mouse no problem at all .... You find a solutions????

Then by default it does not show the dot and dotdot entries. That might be your issue.

Hi, If memory serves well, having network drives can also slow things down significantly.

Ok - I've cleaned up my code as per all the help above. And, I added a slot for the 'destroyed' signal from the QThread, AND, and I added a qDebug statement into the thread's DTOR, and I delete the QThread immediately (not deleteLater). So, I can confirm that the DTOR is running, and I can confirm from the slot that the QThread is destroyed. However...valgrind is STILL reporting memory as lost on the line where I create a new QThread: m_myThread = new QThread(this); I'm left scratching my head. I assume that this is a valgrind - Qt issue. Unfortunately this is already a pretty big program so I can't post it, and I'm sure a MRE will work fine. (I've used QThreads in my other programs without memory loss). Does anyone have an idea what might be causing this? I'm hesitant to open a bug report since this seems odd, and I can't produce an MRE. Hmmmm I use smc-check=all in valgrind, for heap and stack, because of my QRegularExpression use. Could that be confusing valgrind?

Hi, Did you run make update_translations ?

You should try to create a minimal, compilable example and create a bug report then.

This sentence seems to tacitly allow changing the baudrate after opening QSerilPort, and after trying this, I found that serial communication is normal. Yes, you can change the properties (baud rate, data bits, stop bits, etc) in any time.