Bill Meyer

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.

I need to install in Tokyo a set of components from an older release which I can use while waiting for the corporate purchasing wheels to grind on a new license. I am able to build both the runtime and design time packages with no errors. But when I try to install, I get this: Can't load package s:\Inst\Comps\ThisPackage.bpl. The specified module could not be found. The module is present, at the path specified in the error. I am at a loss to know what might be the cause of the problem. I have verified that the dcp files of the units in the requires list are all present. Any clues would be welcome.

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.