Hmmm very odd! I closed and re-opened VS and now it works as expected - though black selection on a black background is VERY hard to see.

This happens to me too. I restart the creator and than it works fine,

Well, this would be a possible workaround, but it neither explains nor solves the underlying problem …

Great, thanks a lot. I've got it from the sharing site. I won't be able to look till this evening, but I'm looking forward to it!

@SMF-Qt I found this bit of java which I think does what I want: PowerManager pm = (PowerManager) getSystemService(Context.POWER_SERVICE); PowerManager.WakeLock wl = pm.newWakeLock(PowerManager.SCREEN_DIM_WAKE_LOCK, "My Tag"); wl.acquire(); ... // screen and CPU will stay awake during this section ... wl.release(); Can this be used with QJniObject class if so how do I do it ?

@Pl45m4 Ja Hab ich. Dies ist die komplette Datei. #pragma once // Includes //--------------------------------------------------------------------------------------------------------------------- // own header // other includes // system includes #include <QtCore/qglobal.h> // Macros/Defines //---------------------------------------------------------------------------------------------------------------------- #if defined(LIBDB_LIBRARY) # define LIBDBSHARED_EXPORT Q_DECL_EXPORT #else # define LIBDBSHARED_EXPORT Q_DECL_IMPORT #endif // Forward declarations //----------------------------------------------------------------------------------------------------------------------

Correct. You cannot simulate that level of fidelity in realtime using win/linux/Qt. You would need to drastically lower your iterative frequency and maybe interpolate intermediate values. Otherwise, Do as I mention and use a synthetic timer that has no ties to realtime. As a safety margin on generic desktop systems don't do timers or trigger timed events at periods less than about 50ms (or 20hz). That broadly covers lower HZ values and "usually" handles scheduler noise. Remember that the Qt timers are more for UI responsiveness than tracking high precision events.

Yes, I also encountered that. Sadly, that's exactly what it means: PySide's asyncio event loop does not implement getaddrinfo: https://code.qt.io/cgit/pyside/pyside-setup.git/tree/sources/pyside6/PySide6/QtAsyncio/events.py#n552 In fact, none or almost none of the IO-related methods are implemented. Documentation also says that directly at https://doc.qt.io/qtforpython-6/PySide6/QtAsyncio/index.html: We consider that this API consists of two levels: Fundamental infrastructure for event loops and asynchronous operations, including futures, tasks, handles, executors, and event loop management functions (see below). A user-facing API for use in applications, including transports and protocols, network connections, servers, sockets, signals, subprocesses. QtAsyncio currently covers the first level.: One solution is to use trio in guest mode, like in this example: https://doc.qt.io/qtforpython-6/examples/example_async_minimal.html. Except it will not help you, because LangChain does not support trio. There are a few libraries that implement a similar capability for asyncio, but none of them seem particularly mature.

@SGaist Thanks but I don't know how that is done on Android.

From a quick search about these error message, it seems to be a chromium on Debian issue. Can you try to start your RPi on an Ubuntu image ?

@JonB read post more once and did through qml thanks an answer

@hskoglund I think this may be the only way to go, especially if the result of the thread interaction requires any sort of GUI (posting error messages, etc.). It does seem that aboutToQuit() is too late in the sequence. Evidence, after some exploration: My problem was caused by a change in Qt 6.5.0 (link) that moved the signaling point from QCoreApplication::execCleanup() (which explicitly turns off the quitNow flag) to exit() (which doesn't). That flag is what prevents a local QEventLoop in my slot handler from spinning up. It's not clear if they meant to do that, but... That change refers to a bug report (link). A comment by the maintainer says, "The docs for aboutToQuit specify 'Note that no user interaction is possible in this state.'" And indeed they do (link).

@DevWinDemon I also use msys2 ucrt64 qt6, may be you can make things better follow these approaches. Copy your exe file into a release directory. Make and run msys2qtdeployplus under the same env, such as mingw64 bash or ucrt64 bash, everything will be ok. the msys2qtdeployplus will do : (1) Call windeployqt5/6 for every exe and dlls in the release dir, and, extra dep dir as needed. (2) Repeatly call ldd/ntldd for each dlls in the release dir, copy extra dependcies from msys64/ucrt64 bin dirs to the release dir. (3) If there were no more extra dlls be copied, goto (4), else, repeat , goto (2) (4) Finished. Before this approach, please make sure that ldd /ntldd, windeployqt5 or 6 has been installed by pacman -S, in your env, such as ucrt64. Repeatly calling ldd/ntldd is very important, for example, Qt SQL psql plugin need libpq, but libpq also has its' own deps, libcrypto.dll and so on. [image: f22d9cd9-76c2-494c-9742-8f8b6efd1078.png] Call upx tool with "find -exec", for every dll and exe in release dir, using lzma and deep trim switchers, that can significantly reduce the files size. upx can be installed by pacman -S.

@ekkescorner Thank for replying. Now I am working in Qt6.6.3, With Android -35, Built the application Successfully, But on android device it shows only a white blank screen with the Name of the application at the top