timfrost

But lack of SeCreateGlobalPrivilege privilege may cause creation of the Mutex to fail, as was mentioned by the OP.

The very simple Mutex may not work if multiple instances of your application may be running in different accounts, with different credentials, or as a service.

I have tried several components over many years, and the only one that has proved simple and reliable under all circumstances is JclAppinst.pas in the JCL. Many options if you need them but for simply checking that there there is only one instance you need only two lines of code added to your DPR: one supplying a GUID and then a call to JclAppInstances.CheckSingleInstance.

I can reproduce the initial screen being too small on my 3840x2160 monitor. But it would be sufficient to fix the failure to save the size between usages, to avoid the annoyance of resizing it every time, and this might not require a matching monitor. I am sorry, but I am not motivated to learn enough about the Gexperts source to discover how/where you prefer to save dialog sizes, because this is a Gexperts item that I have never used!

Since you ask, just some GUI issues: https://quality.embarcadero.com/browse/RSP-30043 Nothing major, just simple and annoying; not included in the fix. https://quality.embarcadero.com/browse/RSB-3800 Equally annoying; included

All of my programs have a custom manifest file, specified using $R in the DPR. I have different combinations of administrator and dpiPM manifests for different programs. Using a $R entry in the DPR allows me to have a common Finalbuilder action for building EXE files, with only a couple of variables needed, and allows me to build either in the IDE or for production. In the IDE, none of my projects specify a manifest. In just one single program, this fails, because Delphi inserts its own windowsXP.res containing an XP manifest into the EXE. In consequence this application, which requires elevation, gets two manifests and the XP manifest wins. Watching the build with PROCMON shows this file being picked up and used. The unwanted manifest is inserted both when compiling in the IDE and in Finalbuilder. I have tried deleting all the project files other than the DPR and starting afresh, to no avail. None of the unit sources or resource files reference this Windows XP manifest. I can get around this issue by removing the $R and instead specifying a custom manifest, but this is untidy because I then have to have to build this program differently from all the others in Finalbuilder. Can anyone suggest what might be causing this resource file to be picked up?

Thanks, both. I had just found that one myself, but of course it is not in the link map, because it contains no code. But it does show up on searching in the full PROCMON listing for bds.exe, now that I have stopped filtering it on windowsxp.res. So I think I can track it down to a form this application has borrowed from elsewhere; not code I have written. This level of detective work is always a fun task for a cold Sunday!

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.

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.

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

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.

@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!

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