timfrost

The ability to exclude areas from formatting is one of the many reasons why I have always used: {(*} GExperts Code Formatter {*)}

It's an IDE feature. Add or delete a file to the project, and conditions and includes in the units list in the DPR are changed in various ways. I opened a quality ticket a couple of years ago and was told it was by design, because 'Delphi manages the DPR file' and can override manual settings.

SysInternals Process Explorer can show the path and version resource of each loaded DLL in a process.

Sounds good, but raises some questions: Is this an alternative to ewriter files or an eventual replacement? Can you summarise the advantages/disadvantages of one over the other? How much change is needed in Delphi VCL applications, or in my help build procedures, to switch to using Ziphelp? And does a download of Ziphelp attract the usual Windows 'block' on zip files?

A delight to use, and very helpful to see project relationships. I also like your encouragement of exploration without needing documentation - I found that clicking on things was more than sufficient to reveal more secrets.

Could you not just have an option to leave things the way they are, and still support Yukon? For people like me, long time users of GExperts formatter, who find it an absolutely essential tool and who will have no problem in resolving never to use a triple quote for its new purpose.

In my experience the bugs in the project settings hierarchy have varied from version to version, but never gone away entirely.

I personally would use Mitec System Information Component Suite, because I already use it for many of its dozens of other information sets. It is probably overkill if you only need this one enumeration, but it's excellent value if you also need more. https://www.mitec.cz/msics.html

With the Windows API you can find information about your own process from its process ID, and in this "process information" is the process ID of the parent process that started your process. From this you can find whether the name of that process is Explorer or EXE1 (or something else). If you are not familiar with all this the API calls can appear quite complicated - look for examples in Delphi of using the Windows ToolHelp API, which includes the functions you need, and for which Delphi provides an interface in Winapi.TlHelp32. There are plenty of code examples around which you can copy but someone else may be able to give you a link to code that does exactly what you need.

Yes, you are right. This code is so old that I had forgotten that GetProcessWindow is in a library function I borrowed from somewhere else, and which as you say uses EnumWindows. And thanks for the Raymond Chen link; luckily no problem has ever surfaced and this small program is anyway about to be dropped because it is used to configure a service which has reached EOL.

In one of my applications I also need just to show a console window in a tab or panel, and I also have no need to capture its output. It's a rarely used option, not a central part of the application. You can get the command window handle by calling GetProcessWindow(pi.dwProcessID), where pi is the PROCESS_INFOMATION available after calling Create Process; and then calling SetParent to set the parent of the command window as your target component. You will also need to call SetWindowPos with the command window handle to position and size the command window over the target component. It's not very pretty, and there may well be more elegant ways to do this, but it is simple, and has been sufficient for me over several Delphi releases up to and including 11.

Winsoft have two OCR solutions for Delphi, one using a DLL and one the Windows RT OCR API. https://www.winsoft.sk/ocr.htm and https://www.winsoft.sk/rtocr.htm. I have not tried either, but they do have a demo and are reasonably priced with no ongoing usage charges.

If you are concerned about performance, use the options in FindFirstFileEx to use a larger buffer and not to return 8.3 filenames.

You might like the Grijjy implementation of Google Protocol Buffers: https://blog.grijjy.com/2017/04/25/binary-serialization-with-google-protocol-buffers/

My CPU is an Intel core i7-11700, and I can reproduce the same symptoms here with Ian's source file on an AMD Ryzen 7 3700X, where Delphi is 10.4 and GExperts is 1.3.21.3833. But not on Delphi 10.3 with GExperts 1.3.14.80, which runs on a core i7-6700T. On the older machine the formatter runs with or without the comment. My guess is that this may be related to the formatting settings; perhaps both Ian and I have settings that you do not. I tend to copy and review my settings manually from IDE to IDE, but 10.3 might be different. And I do not remember whether there is an easy export/import settings mechanism for me to send you my settings to test. I don't really want to update my own GExperts at this moment. I do not normally put comments at the end of interface lines so the problem does not affect my formatting. I only researched the issue because it seemed an interesting bug, and might have been related to the apparently intermittent 'formatter does not run in 11.3' issue which I fixed in February by building from source, following your suggestion here then.