I have noticed this every since (for years, on various computers), and that it has now even caused a crash of DOpus on my Win11ARM/Mac I do not attribute to this particular setup:
When a search is running, DOpus seems so "obsessed" with searching that too much cpu / RAM / whatever is devolted to the search that cancelling the search action does not respond immediately, and closing the search field even caused a crash of DOpus. I would like to suggest that cancelling a search action should always respond immediatey: Clicking the cancel button should always be responsive, and once clicked, the search should stop immediately.
It may not be Opus itself but a component something else has installed which gets involved with searching. If file contents are being searched then the problem may also be antivirus scanning the files, which can block processes from doing anything else until the scan completes.
Which search are you using? The Windows Search field at the top-right of the lister? Or the Tools > Find Files panel?
What are your search criteria?
Which types of files are in the folders you're searching?
Assuming you're using Opus 12, send us some snapshots made while the search is happening and won't cancel quickly. We can use them to see what's going on, and whether the delay is inside Opus or something else.
If you're on Opus 12, your account still says Opus 9, which may mean it's linked to the wrong licence. We can unlink the account if you want to link it to a different licence.
(Linking updates versions automatically if you upgrade an existing licence, but if you buy two completely separate licences for different versions then the system won't know you have one if you're linked to the other.)
As a typical search, lets say "search for all *.txt files in C", or "search for all *.txt files in C containing 'testtext'", or a mistake in clicking that would result in "search for ALL files in C (blank search field)" which will accumulate loads of files as a result and also tends to make Dopus not want to react to "Cancel".
I have been using Kaspersky on the previous Win 8.1 laptop, and just Windows Defender ont the Win 11 laptop.
Licenses: I have a paid DOpus 12 full license with FTP, licensed to Matthias E.... I bought it separately because I kept the old licesense (DOpus 11 or 10) on my old laptop which I hardly ever use, I didn't want to uninstall DOpus there, it's essential
thank you for the kind and quick support
If this does not suffice for troubleshooting - but please only then - I would help more by making a video, but really what is happening is just simply a delay in responsiveness and potentially non-reactiveness of DOpus up to a crash if the user tries to close DOpus in that state. It can be averted by letting DOpus finish the search, or by not over-reacting by clicking nervously to cancel a search.
Ok I can reproduce the problem.
When I start a search with blank search terms on C, dopus search CANNOT bet stopped and it will just continue to search despite clicking Stop. If I close DOpus in the state of it still searching, Dopus will crash, saying, 0x0000 ...5 in thread dopus_lister at adress 0x77BB99F0
On Windows 8.1, Dopus 11 will display the same behavior when trying to stop the search, however closing Dopus in that state will not cause a crash. I tried to provoke a crash but it just closed properly. The behavior that it will refuse to cancel the search and just continue can be reproduced on dopus 11 and 12.
Could you send us some process snapshots from the machine with Opus 12 on it, made after you've clicked the cancel button? Those should be the best way to see what's tying things up.
I've also unlinked your account, which lets you link it to your Opus 12 code.
Ummmm, process snapshots?? Did I sound like I would know what that is I will follow your instructions of course.
It is weird though that you cannot reproduce. I have seen this behavior on 4 laptops with dopus ever since I have started using DOpus many years ago, and irrespective of AntiVirus or anything.