Bill Meyer

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.

Linux is free, not Delphi. If people want to pay for Delphi to build software for Linux, let 'em. So long as Delphi Pro is not free, I don't see that it is "work for nothing".

Agreed. However, they are not starting over, and would be unlikely to do so, with the low popularity of Pascal today. Given the inertia in the existing code, and concerns over breaking changes, as well as the lack of deeply committed language heavyweights on development, I think that the trend to cross-platform is likely to continue to dominate. I would like to be proved wrong on that.

Pesky facts. You cannot do what you wish, with the product which exists today. Facts don't yield to attitudes. Hard to say what the future holds, but so long as the pursuit of cross-platform seems to take a high priority, the enhancement of currently functional language elements is unlikely to be reconsidered, IMHO. You asked how to do what you want, and the answer is that you can't. At least not now. We all have our pet wishes for Delphi features, and I think there could be astonishment at how little commonality of opinion there is.