I don't think QFuture/QFutureWatcher would have such an API. I guess you could query what thread it is at the start of the function you run with QtConcurrent::run and communicate that to your main thread.
Elvis Den tis 4 jan. 2022 kl 20:08 skrev Scott Bloom <sc...@towel42.com>: > > Is there anyway to get (if it even exists) a QThread from a > QFuture/QFutureWatcher? > > The main issue, and I know this going to sound horrible, I would like to > kill/terminate the thread, I know its safe 😊 (famous last words).. > > > > Here is what im doing, maybe someone has a better solution (Im sure of it). > > > > I have a Qlineedit entry that takes a path. Often, this path is network > based, and very often over VPN, meaning its NOT always connected. > > > > On the text changing, the window determines if the path is valid > (QFileInfo::exists, isDir, isExecutable for directories, some are files). > Unfortunately, if the VPN is not connected, it can take up to 30 seconds for > the OS to return “no it doesn’t exist”. (Windows is the primary OS, but I > have seen the same on Linux) > > I have created a “Delayed Line Edit” class, that derives from QLineEdit, that > delays the “the text is edited” by a set amount of time, to minimize the > check (ie when typing the path by hand). > > > > However, at some point this 30 second delay hits, freezes the gui and is an > overall miserable experience. > > > > What I have done, is created a simple Object “Background File Check” that has > all the File Info queries. You set the path, set what you want checked, and > call “checkPath”. This calls QtConcurrent::run on the checkPath internal > function. There is a QResultWatcher, that emits the check has finished or > timed out (with a single shot timer called when checkPath is set). > > 99% of the time time, if its not there in 5 seconds, its dead. So a 5000 ms > timer is used. This works great. Except there is one problem. > > > > If the user tries to exit the tool before all the threads have finished, the > tool waits for them to close. > > > > There is no way to interrupt the single class to the OS, its frozen in the > thread (better than also freezing the GUI). But If I could ask the watcher, > give me your QThread and let me terminate it, it would fix the issue. > > > > Any ideas? > > Scott > > > > > > _______________________________________________ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
