Bill Meyer

I agree completely. That said, they require significant work to remove. And though MMX can present reports on the problem, I am still looking for anything which can simplify the task of identifying the worst offenders. (Yes, it matters, as the full report is a bit overwhelming in this case.)

Your opening comment is very disappointing, given that my first impression of 10.2.3 is that the IDE is slow and flickers obnoxiously. I'm not a fan of themes, so the "solution" is one I can welcome. Is the IDE now perhaps all done with DevExpress controls with skinning? (Just asking...) Successively longer compile times is another disappointment, but having spent weeks now in moving legacy code into XE7 -- where it cannot build, except through the external build process -- has mad me much more sensitive to the numerous defects in the IDE. And I have turned off almost everything that in interactive in the IDE, in the hope of reducing the problem. I will mention, however, that some of your comments lead me to wonder whether your project is free of unit dependency cycles. Mine is not, and I know too well that those cycles lead to many problems. The "stuck" compiler is one of the symptoms I have seen.

Yes, I read your original post. So as I understand it, then, the problem with GetIt makes Tokyo unusable? I did have a similar problem with Tokyo in a VM a couple of months ago. Did the uninstall/reinstall dance, and then it worked. I have my own concerns about Tokyo, but GetIt is not chief among them. That is why I asked.

And historically, some pretty bad parts, it seems.

Care to elaborate on that? I have not seen any such disparaging comments before now.

Quite a few years ago, Jack Crenshaw wrote a series of articles on how to build a simple compiler. He wrote in TP, and develops the whole thing step by step. It is a recursive descent compiler, and originally emitted assembly code for a Motorola 68000. The articles have been further developed over the years, and the target altered to the 80x86. The value is simply that he wrote this for people who are not writing a compiler professionally, but who wish to learn the mechanics of compiling code. The writing is clear, and the whole development easy to follow. The articles can be found here: http://www.pp4s.co.uk/main/tu-trans-comp-jc-intro.html

In the course of some project analysis, it has become apparent that we would benefit from exporting a list of all installed components in Delphi. I have found articles discussing how to obtain the list using the ToolsAPI, but that would mean building a package for a wizard, which is more of a side project than I was seeking. If anyone knows of an existing wizard which would provide the functionality, I would appreciate a lead. Bill

Which code? You posted code for use in a package. I am now scanning the registry, and collecting from there with my own code, which works fine, though there are a few idiosyncrasies in the lists there. The point of my last post, though, was that although the registry scan is convenient, it is specific right now to XE7. And given the minor irregularities I have found in the entries there, it seems reasonable to anticipate irregularities in other versions, whether the same or different to these. In D2007, however, I find no evidence of installed components in the registry, so in the end, the ToolsAPI may be the only reliable approach.

As it happens, I need to run in XE7, where the key is this: HKEY_CURRENT_USER\Software\Embarcadero\BDS\15.0\ToolForm\Mapping. I also have an interest, though no absolute need, to run this in D2007, but I find no entry in the registry for such information. Has anyone committed a web page on the variations of such content in different versions?

I will give that a try, Uwe, thanks.

Determinism is overrated. 😉

When you're right, Lars, you're right. Unfortunately, for reasons of logistics, it is a necessary step.

Looks nice! Now, on a more serious note, I am dragging a very large app forward in time (from D2007), and trying also to untangle snarls of legacy sins. Bringing code into XE7 has been a necessary first step, and has shown me just how easily the IDE's internal systems can be compromised. Killing and restarting the IDE a few times an hour is annoying. So are the Out of Memory error. I freely grant that many issues are caused by poorly written code, but the rework can only be accomplished if a stable environment is available. One example is the minor editing of an interface uses clause which all by itself provoked a rising memory burden until it was necessary to kill and restart. In a few cases, I found it easier to simply use Notepad++ to edit the file, and then reopen in Delphi. All versions work fine on small apps. But large apps filled with legacy code are an everyday reality.

@Dany Marmur No problem. I also found: https://github.com/ADUG/DFMJSON

DelphiAST seems a bit unhappy with DFM files. Anything in particular we need to know?

Given that I doubt we will ever see a fully repaired IDE, the language server would be a boon, were it not for the issue of a form designer. The notion of using a CSS-like solution reminds me of the Regex joke: I had a problem, but solved it with Regex. Now I have three problems.

Good info. I am on the verge of tangling with that beast, and am glad I won't have to find my way to that approach on my own. I know the DevExpress components are well liked, but I find a good deal of their stuff to be overly complex. And the documentation seems only to be reference material, not introductory and tutorial. Facing a 4,500 page reference manual is a lot like having no docs at all.