timfrost

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.

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.

I have never liked the idea of a hash, and I use an implementation of a ternary seach tree as a dictionary. I based it on an article in Dr Dobb's Journal in 1998, and it has stood the test of time! I have versions for C and Pascal; the latter for AnsiChar, WidwChar 32-bit and WideChar 64-bit keys. It is incredibly fast and easy to use, and has reasonable memory consumption, unless of course you load a million random 100-byte keys (which takes only a second or so). It has various ways to load and look up keys, and to traverse the set; values can be integer, object or string. I use it it in many different ways, both to match a full key and to find the longest initial partial key. On updating a value, the space used by the old value is not recovered, but that suits most of my uses as a dictionary; and the unit does include a function to rebuild the data store for a dynamic application, if you can spare a second to do so. In its simplest form: tree := tTSTtree.Create; tree.insert(key, value); q := tree.match(key); if (q <> nil) then s := string(pchar(q)); The source is reasonably well commented, and I would be happy let you have a copy, but I have never got around to properly documenting it and uploading it somewhere.

Yes, problem completely absent in 10.3.3. I have withdrawn my vote for RSP23655 mentioned above.

Yes, there is also a CopiedPaletteItems value in the key (mine is empty) and I think I spotted in Procmon a check for a DeletedPaletteItems value (which I do not have). I agree with your conclusion; the main value (a huge string on my system) is not a pool that I want to paddle in. And that was decided after only looking at the leading characters of the string visible in Procmon. Probably any attempt to reverse engineer it would technically violate the licence, so I am going to stick with the way the palette is now. Over the years I have got used to finding recently installed components near the bottom, and most often the ones I need can be found quite quickly from the substring search. Just close that box and lock it!

I had the same thought, and I could not find them, which was irritating.... So I fired up PROCMON, filtered on bds.exe, and moved Additional down below Win32 in the Palette list, which caused a flurry of registry accesses. You can find the list in a long SZ value, in HKEY_CURRENT_USER\Software\Embarcadero\BDS\20.0\ToolForm\Mapping\(Default). Over to you; I am not sufficiently motivated to attempt this!

If you have lots of time on your hands you can sort them manually by dragging up and down, in the main window or the pull-down category list!

It would be helpful if you could say what you propose to use the resource file for. I have dozens of resource files but they may not be relevant for you. What happens if you compile an RC file containing: STRINGTABLE BEGIN 1, "Hello" 2, "World" END

There is loads of stuff which is useful for this type of task at the old EFG graphics library site http://www.efg2.com. The site still exists, but only links to the Wayback Machine now. I needed to find backgrounds of light colours to change to white and of dark to change to black. There is an EFG utility function CountColors which builds a sparse table of the frequrency distribution of each color, which you might find useful, and many others if you need something simpler. Unfortunately I cannot remember which source file I found it in, but I could send you that routine if you cannot find it, Choose a Wayback Machine snapshot a year or so ago (before the site closed) and have a browse. Edit: the function I referred to is in showimage.zip in ImageProcessingPrimitives.pas. You can find the zip from Show Image in the main menu.

@mrpmorris Good to hear from you again in a Delphi context! I don't think I ever used DIBControls, only FastStrings. I find this was 20 years ago now, in 1999.

Without managing the global library path, a package manager would not work for me. I cannot think of any library we use that is not used by multiple Delphi projects; in some cases dozens. So no project search path is ever used or needed. Are you targeting just the type of development shop which builds only one or two huge applications? But don't pay too much attention to this comment, because as I have said before I am very happy using a Finalbuilder project as a DPM.