timfrost

PlusMemo (www.ecmqc.com/ecmhome.htm) is an excellent and well-supported editor component; low-cost but not free.  It  comes with an add-in for line numbering.

Can you add to Github a note of precisely which operating systems this supports?  At the start of this thread Windows 10 Creators Update or later was mentioned, but this is not made clear as far as I can find.  What is the fallback on an unsupported OS?

Why is SVG so flaky when used in desktop applications?  I have SVGs created using major commercial and free applications, which display without problems both in other applications and in any browser I choose, but which fail miserably to display in any of the Delphi libraries I have tried.  The library authors seem to feel that once they can display the tiger and a few simple geometric-shaped icons, the product is ready to ship.  I would like to display a variety of logo images and diagrams using SVG, not just small icons on a menu bar or button.  But as soon as an image involves 'text on a  path', or complex patterns or shading, or some other common graphic style, each library I have tested gets it wrong; and not even wrong in the same way that a different library or a similar example gets it wrong.  SVG would be a great solution if only the implementations worked reliably with any valid SVG file.

14 minutes ago, Remy Lebeau said:

Eldos SecureBlackbox provides an Indy SSLIOHandler for its own SSL/TLS implementation

Provided, not provides; and Eldos no longer owns the emasculated remains of this redesigned product.

But the original code was surely much easier to  understand and maintain.  And who can say whether the last one is 'better'?

What surprises me is that nobody has jumped in with a one line incomprehensible Regex.

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.

8 hours ago, dummzeuch said:

which is really a waste of energy

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.

Renaming the key solved the problem and I think I have my settings the same.  Thanks!

I have a problem installing 15. The pop-up asking whether to use settings from v14 just hangs, even if I click No.  Clicking in the dialog then just gets the standard Windows 10 'not responding' messages and I have to terminate Delphi.

I  tried uninstalling 15, and although 14 is still in the Programs list, it is no longer in Delphi.  Then reinstalling 14 works and Delphi starts.  But this problem recurs if I reinstall 15, so I am now back to 14 for a second time.

Exactly.  Stripping out every UTF-8 BOM is not viable unless all users of the files will only ever use a single national language and its encoding.

I have looked into this for our SMTP (server and client) applications, but have done nothing about it yet  It seems to me that implementing IDN is the easier task, because Microsoft provides functions to do conversions in all the OS which we need to support (https://docs.microsoft.com/en-us/windows/win32/intl/handling-internationalized-domain-names--idns).  What is much harder is getting the SMTP headers correct, as you mentioned at the strart of this thread, which requires clients, servers and MTAs to support the necessary SMTP extensions.  I found a useful brief summary, with links to all the many RFCs, at https://en.wikipedia.org/wiki/International_email but I suspect there is a lot of work needed to get it all working.

We have email server and client users in Japan, the Middle East, and other potential-user locations for this capability, but nobody has yet asked for it.

I got similar results for loading (6.25ms) and finding (9.06ms) in a ternary search tree.  And the StringHash(65536) load time for my list on my machine was 9.4ms. Looking at the StringHash source, the memory usage of both that and TST is the same order of magnitude, but the StringHash makes much more use of strings, of course.  The TST meets my needs, and I have no plans to switch, mainly because my function builds in more load helpers and matching features, which fit with how I use it.