Bill Meyer

I mean that not all patterns fit all languages. XAML is not a feature of Delphi. Examples have been written of MVC and MVP in Delphi. A book has been written about MVVM in Delphi, though it is not clear that what it describes is actually MVVM -- an objection raised by Stefan Glienke, to whom I defer. In my experience, one of the most common patterns in Delphi legacy apps is the anti-pattern of large routines on forms in event handlers. That is something the double-click on a button and write code makes all too common. Thoughtless coding. Patterns are no guarantee of good design.

Particularly since MVVM appears to have been created largely to fit the specifics of C# and XAML.

Oversimplified, but Brooks demonstrates that adding programmers to a late project makes it later, and shows why that is inevitable. Make time to read it. Your guess is correct, if the "problem" is defined broadly, for example, the compiler, the code editor, and so on. Thinking that smaller chunks may be attacked in parallel is risky, unless you have a very clean architecture and minimal coupling. And tasks defined and assigned by a product architect.

In Delphi XE, I see that the Ctrl+Alt+M shortcut is assigned to the View Debug Modules menu item. I used GExperts to remove that shortcut, as I do not much use it, and it conflicts with the MMX Add Method shortcut. I now see in GExports that there is no conflict on Ctrl+Alt+M, and that the shortcut is still assigned to MMXAddMethodAction. Unfortunately, the MMX command still does not work. Tried restating Delphi, and it did not help. Have I missed something, or is this not functional in XE?

I have questions regarding SynEdit-2. What is the earliest supported version of Delphi? What are the dependencies on other packages? I ask because I have tried two versions of Delphi, the latest being 10.2.3, and neither one will build the runtime.

Context frames pragmatism. Mil-spec is a notoriously unreliable category. Many years ago, I was regaled with stories from former employees of a major semiconductor manufacturer of shipping dates met with chips which didn't even have the right number of pins. On the other hand, I contend that the simple PC power supply is one of the most reliable devices on the planet. I can't recall the last time I had one fail. Some of the assertions in this thread display a serious lack of real thought. Choose the wrong device, and you can't compete on price. And if the customer is more sensitive to price than to the occasional failure, that is a critical error to make. There is a very famous tale of the time the master computer on the space shuttle disagreed with the results from the four lesser devices which checked its work. They decided to believe the master, on the premise that because of its stunning cost, it was more likely to have been well programmed and well debugged. The four lesser (6502-based) devices were correct.

You are correct, of course. I think I copied that from help, though. Should have checked more closely.

I routinely operate in VMs, and my largest are given 6GB. I have one such with Tokyo in which I build an app where Delphi reports nearly 5 million lines of code.

In D2007, I have the Offset argument.

Can't tell you when it was added, but it is present in D2007.

Does using a defined type play any part in reducing the bloat of generics?

In my experience, the initialization section is dangerous. When you have a large legacy project with many unit dependency cycles, and begin working to clean up that issue, the changes in uses clauses may lead to reordering of the initialization sequence. I found it necessary to log the existing order, then replace initialization sections with InitializeUnit procedures called from an initialization manager. That let me proceed with the cleanup. Without that change, I soon had an app with a lower dependency cycle count, but which did not work.

You can open the MMX Code Explorer, and drag/drop to Object Inspector area.

I had found this advice on stackoverflow: Easy way to solve this issue is to add a post build action to your run time project: copy "$(OUTPUTDIR)\$(OUTPUTFILENAME)" "$(BDSCOMMONDIR)\Bpl" The command above copies your run time file to the default IDE Bpl location. I tried it, but again got the same error. I also tried without that, and adding my BPL location to the PATH, as another thread suggested. That also failed.

There is also the question of disk thrashing defeating the parallel approach. You can get a hint of this in BeyondCompare, if you set up multiple large copy operations, and run them in parallel.

The net license needs to reach the server at least every 30 days, so you are not on a very short leash. On the other hand, if the doors closed, you could be toast in 30 days.

The old components are A problem, and certainly can be significant. I've dealt with this in the past, and am doing so now. And it is not only that old components are an issue, but that it is common to find in legacy projects large numbers of components, because there was a natural tendency to want to try the latest shiniest toys. This wide range of components to be replaced increases the technical debt to be paid. And yet, I would not want Embarcadero to expend monies and development resources bringing these into compatibility with current compilers. (And which current compilers, come to that?) This I would doubt to be practical. Look at the current license fees. Those seem insufficient to pay for the extent of improvements we would all like to see, but you would divide these resources to apply some portion to legacy issues? That will clearly work against the rapid advancement of the product. OSS is such an interesting swamp. For Embarcadero, the obvious problem is revenue, which the rising license fees suggest is less than they wish it to be. I fear that part of the problem is that they (like politicians) fail to adequately consider that the relation between fees and revenues is elastic. Doubling the fee will not double the revenue, as it will drive some not to renew. Basic economics. But will any company wish to buy Delphi to take it to OSS? The world perceives that Delphi is dying. They need not be right, as perception drives action. Idera, having spent a good deal (we assume) to acquire Embarcadero, will want a good deal for it. That suggest the need for an OSS company with deep pockets. How many such exist? And as they are almost universally committed to C and C++, where would be their motivation? Acquisition of a market of uncertain size for a product which many choose not to renew annually? Further, OSS is itself no guarantee of future success. In case you missed it, the consistent mantra has for years been that we (the market) are clueless about marketing. And about the relative merit of improvements, enhancements, and repairs. And that is an inescapable part of how we came to be where we are now. I can envision many changes which I think would be beneficial for the future of Delphi, but as none of us is in possession of any meaningful data regarding market, revenues, and so on, it is purely speculative.

And to be very clear... anyone who thinks that letting me install my old D7 will have ANY impact on sales of more recent licenses is clearly ignorant of the product, as well as the market.

Why not ask the publisher? info@texteditor.pro I have found him responsive.

I have no issue with a limit on the time in which versions could be downloaded, but prior to the recent bump to installation counts, I learned the hard way that my venerable copy of D7 could not be installed as licensed, despite my having the installables and the license code. And I am sorry, but that's a bad policy. Back in the day, I used to license new releases whether I needed them or not, just to support a company I valued. Now we are asked to pay impressive license fees, and if we do not stay current, we lose the ability to reinstall old versions, which may occasionally be needed for one reason or another. And curiously, the mantra has been that developers don't understand marketing. Sorry, but that dog won't hunt. Any of us who have made our living through contract work or custom development certainly have hard earned knowledge of marketing. And as to marketing, any recent promotion of Delphi apart from embarcadero.com?

The rest is a guess based on historic practice. Makes me just as right or wrong as any other speculator. 😉

I think you will find that it is not a change in policy, but that they have been given permission to write about the coming release, which is likely to appear rather soon.

I have had success with ProDelphi, which has been well maintained. My only complaint is that as it will instrument a maximum of 64,000 routines, on large projects, you must enter a list of folders or files to exclude. That said, I have been very pleased with it over the years. There are 32 and 64 bit versions for Delphi and for Lazarus, and the price is low. http://www.prodelphi.de/

Yeah, it's in the fine print. 😉 I learned that one only in the last few years.

My colleagues tell me they have identified a problem in the copy of superobject which we use in D2007. The problem is not present in the version we use in XE7, but I am not aware of what may be different, and no one appears to have noted when and where the two versions were acquired. I am also told that there have been a great many forks of superobject, which makes it all more confusing. What version do people here use, and what is considered the gold standard now, if there is one?