In my book I wrote that we may be the enemy.
Delphi is a powerful tool, but is not free from defects. Any non-trivial software has defects. All too often we may find cause to complain of the IDE, and some of those complaints are surely justified, but what role have we played in introducing issues?
Keep in mind that the Delphi IDE is a single process. As such, it is subject to the limitations of a Windows application. Moreover, it is a 32-bit process, which means limited resources at a time when we are accustomed to thinking of memory as a cheap and almost inexhaustible resource. The machine on which I write this has 64GB of RAM—but Delphi can use only a small portion of that. Note that the introduction of Language Server Protocol (LSP) in Delphi 10.4 alters the process situation.
You may have been irritated to see the Out of Memory error. Perhaps even frequently. Let’s consider what you may have contributed to that situation.
- How many hundreds of components have you installed? And how many of them do you actually use in your applications? The component BPL files consume memory, and create the possibility of the visual form designer few of us would give up.
- Is your application a large one? Are there thousands of modules involved? And have you investigated the issue of Unit Dependency Cycles? I spend a good many pages on the evils of UDCs in my book. They increase the burden on memory resources and degrade build times. I won’t repeat all that here, but bear in mind that the effect of UDCs on build time is exponential. The exponent is a small one, but as units use other units, and each of them create circular references, things grow worse, and eventually, instead of seconds to build, you may be seeing build times of several minutes.
- Do you create components of your own? Are you persistently critical of the coding there? Do you tirelessly root out every possible source of waste and of unhandled exceptions? An unstable component can make the IDE unstable. That comes also from the reality of components in BPLs being live in the IDE.
Do you have IDE plug-ins which don’t work as expected? Many of us use GExperts, a very fine plug-in, and one of its useful features is a grep search tool. An important feature of the grep search is that you can constrain it to search in the entire project or project group, rather than having to specify folders. But the search may throw an error with a list of files not found. This is another self-inflicted wound.
- If you remove a module from the project by deleting the module file(s) you are not following a logical process. The correct flow would be to open the project and remove that module from the project, then delete the file(s).
- The compiler does not complain when a module of the project is not found, unless calls into the module are made from others. As the module was being removed, we may assume there were no such calls.
- GExperts, however, in its grep search, looks for the files in the project, and when one or more are not found, it publishes an error with a list, and does not complete the search.
The repair is simple: Open the project and in the Project Manager, close inspection will show the icons for missing modules are different than for those which are present. Remove each from the project, and you will then find that the GExperts grep search completes as it should.
We are not wrong to wish for defect-free tools. But we must be vigilant in ensuring that we do not create problems in those tools.