timfrost

I have used a Clever Components support ticket (I have never had any other way to contact them) to send Sergey a link to this thread and ask him to comment.

Clever Components is one of our software-library suppliers who used MyCommerce to process payments. We last paid for annual support/updates renewal in March this year, which may have just squeezed through to Clever before Digital River went quiet; or may not. Reading how other vendors have been affected makes me wonder if Clever have been starved of funding also.

When I try to run the pre-built executable linked from Github, on Windows 11, I get either a runtime error 217 or a crashdump, depending on the current directory of the exe.

I would try Process Monitor from SysInternals, filter on the bds.exe process name, and check what it's 'last words' were before dying. It may give you a clue.

I cannot believe how complex this discussion has become! All to avoid having a tiny unit with four boolean variables defined in the interface, along with a GetLogLevel function which can be called when needed, and then writing, for example: if LOGINFO then log(MyComplexStringExpression); if LOGALL then Log(AnotherExpression); This seems to meet all the criteria of readability, simplicity and efficiency.

I have used bits of their Internet Suite for over a decade. Looking back over the few tickets I have opened, the response time has varied between two and ten days. Not much more than it used to be when Sergei just responded to e-mails. I agree the help file is a bit primitive but they also have a large library of examples and tutorials for the Internet Suite on their site and on Github. I know nothing about their other products, but the ones I use are pretty solid. For this reason, and the fact that I have the source code, I have never really worried about where their offices are, or how many people are in the 'Clever Components Team' which appears under Sergei's e-mail signature.

Bravo! And please do not abandon a simple source download, for people like me who dislike having to struggle to work around an unnecessary version-control system to get what I need.

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.

I can reproduce the same problem with your unit (but not with any of my own). My GExperts build reports itself in 'About' as "1.3.22 build 4008". I think I built this from source back when 11.3 first came out (see another topic here) but I see the same issue (and the same build number 4008) in your unit with the installer with the name 2023-03-25. Although no formatting of your unit takes place, either with the keyboard shortcut or the menu, the IDE offers to save it on close, so believes something has changed. If I remove your comment on line 22, the formatter works correctly. Adding a comment at the end of an interface function definition in one of my own units also makes the formatting fail to take place. So this looks a bit like a data-related formatter bug. I will see if I can find 1.3.23.4026 and try that also.

Can you not find a better 'text extractor' which produces more useful output?

Something has recently broken my object inspector in Delphi 11 update 3, running on Windows 11. If I click in any field, for example 'LeftMargin', the value is highlighted, but digits I type do not appear, and I cannot select any other field until after have pressed the Enter key, when the typed number also appears. If I had last pressed up-arrow, the value next above in 'Left' is highlighted, and again I need to press Enter before I can select any other item. If I have clicked in another item before pressing Enter, the click has been remembered, and the focus moves to the last clicked item when I press enter to clear the original selection. My only items in the Experts registry list are Beyond Compare and GExperts, and removing them and restarting the IDE does not fix the issue. The problem affects all projects and forms, even brand new ones. I have found no other applications affected. Rebooting changes nothing. What should I try next? The Object Inspector is effectively unusable.