Bill Meyer

Refactoring is rarely simple, but it is essential. Redesign can be even more of a challenge in legacy code, as there tends to be a lack of documentation, and often poor naming practices obfuscate the purpose of the code. I don't see any way that the IDE could be held responsible for performing to overcome the creation of developers.

I was not speaking of components or libraries. But all of the units you write for your application should be in the DPR. Relying on the search path does affect the IDE, whether we like it or not. Yes, there are defects in the IDE with regard to Code Completion and Error Insight, but following lazy practices which can be shown to exacerbate the problem is just foolish.

I think there is never a good reason to tolerate unit dependency cycles; they are a consequence of bad design. Again, if you do not see why unit dependency cycles should slow the tools, there is much of the internal action of the IDE which you do not appreciate. As Anders Hejlsberg said in the video I cited earlier, "...as soon as you type a character, you have broken the code." That is meant no literally, but in the sense that any new character in a code file provokes rebuilding of parse trees. It's good that you are getting your feet wet. I have been developing tools to address these issues for the last couple of years, not as a pet project, but a part of my current employment, and I assure you, it is not nearly as simple as you seem to believe.

There is little question that they are a design weakness. In fact, that is a gross understatement. The apparent need for such cycles is a clear indicator that some units contain things which should be separated. Often a class has become a Swiss Army knife, providing too much functionality, marginally related. That's bad design, and substantial refactoring may be needed. The same pathology can be introduced, however, in simple procedural modules, where once again, too many loosely related elements are kept together. Unit dependency cycles: are multiplicative, so should be eliminated as early as possible exact a penalty in build times, and in one major project, I have seen exponential increase in build times as new modules are added, using the old render code analysis difficult, at best are often difficult to remove, as they usually require redesign I have observed that unit dependency cycles are often commonplace in legacy code projects. Further challenges lurk where such tangled modules have been recycled into new projects.

As to the class constants, I must assume it is a defect in the IDE which is tied to the parser used for code completion. In my comments, I did not say that the tools do not work; I did identify factors which affect performance. There may well be other strategies which might be applied to avoid the issue with search path, but I consider it poor practice not to name all your own units as members of the project. Unit dependency cycles are a whole other issue. I can suggest you watch Anders Hejlsberg's video on modern compiler construction. Or just consider with a whiteboard what happens with a small collection of units (A, B, C, D) when: A uses B, B uses C, C uses A and B uses D, but D uses A and B. It's a mess, and when you consider a larger application, the mess is multiplicative. If you see no reason for the result, I submit you may have spent little time understanding the process. I have spent a number of years dealing with legacy code in large projects, and untangling things is a challenge.

I've read many complaints about speed and stability of the IDE. And I have made many such complaints. But in fairness, I have seen in large legacy projects that there are many things we can do which undercut the performance of the IDE. For example: Leaving units out of the DPR, relying on the search path. Slows code completion. Declaring const field members in a class. (D2007) Breaks code navigation below that point. Accumulating unit dependency cycles. Slows IDE response, but also slows the compiler on full builds. There are other "thoughtless coding tricks" which may also contribute to poor behaviors, but those three are big. Also, how many third-party components have you installed? Are they all solid and stable? That has been a risk area since D1.

I have updated my settings to disable notifications, yet I keep getting the dialog where I am invited to accept notifications, whenever I come to the site. It becomes annoying.

On further experimentation, I see that the behavior is specific to Firefox, and does not happen on Chrome. Perhaps is it an effect of privacy settings?

I've no doubt Delphi is an outlier. The powers that be clearly failed to recognize that the books in the box represented a significant fraction of the value of the product. Also, there are numerous products for which "documentation" means simply a reference manual, and though such is essential, manuals discussing usage and library application are also important. Delphi once had an array of volumes, and they made it much easier for newcomers to the language to be productive quickly.

To remember when things were documented is to be old.

Also keep in mind that they've told us for 20 years now that we don't understand marketing. Perhaps not -- I certainly do not understand THEIR marketing. But in my career I have learned a good deal about customer retention. According to LinkedIn, his title is now: Mergers and Acquisitions Executive Advisor at Embarcadero Technologies. And that does not seem to be marketing.

Installed Delphi 10.3.1 Starter Edition the other day on my personal machine. Although the experience so far is generally positive, I note that with the IDE on my screen 2, when I run my app, the IDE moves to screen 1, and the app opens there, as well. Thoroughly unpleasant behavior, and quite unexpected after so many years of multi-screen operation in Windows. I see RSP-12271 and RSP-12956. The earlier case is now nearly 4 years old. One might think such a behavior would get quick attention.

Smacked myself on the forehead over that. Thanks.

Many do use VMs. Many did not in the days of D5..7.

As with most generalizations, there is probably some truth in your comments. That said, the relatively small number of books I have acquired from Packt have been better than average. In particular, they have done a very nice job with e-books, which for code, are notoriously difficult to format well. Very few publishers will consider a Delphi title any more, so self-published books and books from Packt or perhaps Manning are among the few available resources. Packt also publishes some very capable authors, and I certainly number @Primož Gabrijelčič among them. Self-publishing is not a valid condemnation, either. Our own @Dalija Prasnikar published a very worthwhile volume on memory management in Delphi. (Full disclosure: I did assist with proofreading and editing on her book.) Equally, some self-published books on Delphi have been pretty disappointing. Software development books appear most often for well marketed language tools, whether they are expensive or free. One metric I have watched is price per page. When that goes higher than five to eight cents, the book better be excellent. Sadly, that is not often the case.

Maybe. But I thought I remembered having been able to "buy" a free special at the $0.00 price in the past.

Do you have an account registered? That may be the key to getting the free download. I've found the site a little confusing, but once you have a title, you have it registered under your login, and can access it repeatedly.

Worth watching for insights into the value of a language server:

The history of stupid licensing conditions in the USA is as old as shrink-wrapped EULAs. The one ray of hope was the original Borland "just like a book" policy.

Had an unpleasant experience with the license server last year, which necessitated a new slip file. Although the license shows perpetual, there is a subscription expiration date in the license, and that seemed to be an impediment if it became necessary to install new, as in creating a new VM. Also, the license server "solution" requires that Delphi be able to reach the server at least every 30 days.

Wow. Masterful marketing. This will make it easy for any who have considered dropping off to do so. For years, we have been assured that developers simply don't understand marketing. That may be true, but clearly we are not alone in that deficiency.

"Most highly valued" is not equivalent to "most valuable."

Coming into a project which has built for years on the philosophy that a "sole developer" could deal with things, and then success led to 10 or more developers, I have to say I think it is best to plan for success. Legacy code is too often very ugly.

After all these years, I would have thought this should be simple, but apparently not. My app needs to be able to send mail via the installed default client. The assumption is that MAPI will be used, but if that is an issue, I suppose it could be changed. My problem is that on systems with Outlook, I have not been successful. If I install Thunderbird, and set it to be the app for mapimail, it works fine. But obviously, I need to be able to send where Outlook is the client. I have been reading Microsoft docs, and checking registry keys, and still have not found a clear answer to why some systems work and others do not. That said, I have never been a specialist in this area, so my own ignorance of the mechanisms is an impediment. I would appreciate it if anyone can offer a simple and reliable solution.

Not an option for me at this time. The current solution seems to work correctly, but with an attachment, and where Outlook is the default client and gmail the recipient address, there is a second, phantom attachment. It proves to be 32K of memory image. Where the default client is Thunderbird, or where the destination is not gmail, we do not see the phantom attachment. Also, the phantom does not exist unless we pass a recipient address in the call to send MAPI; if we pass only the attachment name(s), then no secondary is created.