timfrost

I see Indy help in the IDE menu under Help / Third-Party Help

I see from the response to Vincent's post in the TMS forums that Roman is already working on this issue in FixInsight.

There are two simple enhancements that can be made to Delphi FindFirst (which I never call, having adapted it into my own version as a replacement). I do not think that either will help you search a Samba network drive, but together they can significantly enhance file searching on Windows file systems. The secret is to call Windows FindFirstFileEx instead of FindFirstFile, which is used both by Delphi FindFirst and therefore also by TDirectory.GetFiles. On modern OS, the 'Ex' function allows you to opt for a larger buffer, and also to omit the double search for the 8.3 equivalent alternate names in addition to the full file names. Once you have set up the 'find' optimally in this way, you can call the standard FindNext and FindClose functions as usual. MSDN has the details you need for FindFirstFileEx. But to address your question, my guess is that your recursive search would turn out to be faster than multi-threading the subfolder searches, if you were to measure it. And measuring in your own environment is the best way to get the answer.

I develop on a machine with 200 and 120 dpi screen and simply make sure that all the form DPI settings are set to 96. In Delphi 10.3, with per-monitor DPI enabled, this usually 'just works'. When it does not, the cause is usually a component which does not handle the 'before' and 'after' MonitorDpiChange events properly or at all. There are fewer of these around these days; but we still have a few which required either source modification, or adjustment of their settings by handling these events in our application.

Basically you will need to set the cache values to zero, otherwise the cache will show you the state of the file as it was several seconds ago. Windows file handling has long been optimised for long-lifetime database files, not for files that come and go quickly. If this is a new application you would be better off with one of the alternatives already suggested.

There is a function to list the pending updates in Mitec tools: https://www.mitec.cz/msics.html. And there is a Windows API for Windows Updates which this uses.

Are you attempting to monitor file existence on a network path? If so, Windows defaults to misleading you about this. Look at the description of the 'cache lifetime' registry keys at https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/role/file-server/.

Each Windows process will have a process ID. Can you not track the process ID in order to identify which one you need to interact with?

I have had a similar problem with external DLLs. In our case we already had an exception handler in the calling C program which caught the exception and could display the stack in our log file. For Delphi main programs, we also use MadExcept which can do the same thing, as do functions available in the JCL. Then use something like Process Explorer to display the load addresses of all the external DLLs in the process before the exception occurs, and DUMPBIN /Exports to display all the entry points of the DLLs involved in the stack. None of this will solve the problem on its own, but having the names of even a few of the functions that appear in the exception stack may give you some clues. The simplest possible example, as David H suggests, will also help.

You could always leave it overnight helping to research how to attach an antivirus to covid19. https://foldingathome.org

@Arnaud Bouchez Yes, and thanks, that is the most likely fit to the circumstances, but I had searched hard and found nothing. However I finally decided to run Process Explorer sorted on CPU time with the fastest possible (500ms) refresh times. There are a number of processes that float around the top of the list on those settings. After several attempts at keying shift-F9 in the Delphi IDE I spotted (once only) that Snagit showed for the half-second at the top. And indeed it was one of the Snagit hotkeys (that I always disable) that had somehow been stolen back for Snagit. I had made (and forgotten) some adjustments to the Snagit settings earlier this week. I hope that this search technique may one day help someone else with a similar problem! @Uwe Raabe just found the solution before you posted it!

What could have caused Shift-F9 to stop working in the IDE since Tuesday? F9 and both shift keys are fine on their own, as does Shift-Control-F9, and the problem still occurs when the IDE is the only application open on the desktop. Selecting a different keyboard mapping set which also uses Shift-F9 to build makes no difference, but one that uses F7 works normally. I have tried disabling all the items in the "enhancement modules" list.

@mael OK, but my original posting made clear it was not a competitor. Apologies for getting diverted by the reply to it.

Well, yes, you do have to pay for excellence. But $20 for 6 years use, and updates, is a steal; and when I first started using V in 1998 the licence was perpetual. Prompt support and response to feature requests, too. It's a classic which nobody should be without!

As a file viewer (not editor) for very large files and with UTF8 support there is nothing to beat V from fileviewer.com. I ignore all the file-manager stuff and use it, daily, as a file viewer.