Bill Meyer

Looks like the domain registration expired on 2021.10.31.

Found that the existing installation was for current user, and I was trying to install for all users. I am also finding that MMX operations sometimes do not work. Edit Entity, for one, and Format Uses Clause, for another. It appears to have something to do with the unit. Maybe. Still trying to puzzle out the misbehavior.

Downloaded 5 minutes ago, MMX_Setup_15_0_48_2480.zip Installed to Tokyo. Ran the IDE, and it reports 15.0.38, not 15.0.48. Build 2440, not 2480.

I have a substantial collection of forms which may be changed from fsNormal to fsMDIChild at runtime. Not my doing, but my inheritance. Yes, it is wrong and should not be done. But I wonder whether there is a way to minimize the unpleasant artifacts.... The right way, I suppose, is to produce from each form a frame which contains the functionality, then create two forms, one fsNormal, the other fsMDIChild, as hosts for each of these frames. Eventually, I will go down that path, but still hope for a tolerable short-term approach.

Thanks! Will be glad to resolve my misunderstandings of the issue. Curious, though, why the Delphi help recommends strongly against doing it.

Much appreciated!

That would be great. I have some two dozen forms which are affected in this way, and would prefer to keep things relatively simple.

First, I suppose because Delphi help warns against it. But based on observation, it seems to be responsible for the appearance of an empty form, followed later by the populated form, down and to the right from the empty one. Looks sloppy.

I have some old components which make of units like ExptIntf, which have long been deprecated. However, I have not found in my searches any help or blog articles about how to replace them. Any suggestions?

I have a large project I am moving from D2007 to Tokyo. I have reached the point of putting an executable up on a server for QA to exercise, and learned then that it requires the deployment of a number of BPLs. As far as I understand it, these settings should make that unnecessary, However, after building, I see this: Any guaranteed solution for the problem?

Thanks. I am getting there.

In that case, the dependency on DesignIde must be eliminated completely, not merely isolated to the realm of the component in question. If my understanding of the issue is correct. Or is this the issue which requires the separation of run time and design time component packages? I suppose that must be the real issue here.

One might (foolishly) think that in the help article which explains using -LUDesignIde some mention could have been made of the consequence. Thanks.

It is added in the options with -LUDesignIde because of a home-grown component which requires the app to reference the DesignEditors unit. More than that, I can't explain, as I am too far out of my element there.

So the numbers are not specific to the page(s)? Affinity Publisher https://affinity.serif.com/en-us/publisher/ is an inexpensive tool which can edit a PDF and you could put the ID numbers into what they call master pages. That would remove the need for editing all the pages.

Don't know. I should have mentioned I am not spending time on W11. We've only just updated production VMs to W10.

And here we are... another Windows with eye candy, but I wonder how many of the broken basics have been repaired. - MS Teams statuses are all but useless, as the update process is unreliable, at best. - MS Outlook instances seem to insist on maintaining individual statuses, so when all email has been read read in one instance, another instance shows unread mail. - MS Office shared docs are dicey, as the status synchronization there also is poor. - OneDrive? Don't get me started. I'm sure we all have Windows issues we simply learned to tolerate.

There are worse:

Then from my own experience, I would say you will have to work up your own solution. The DevExpress component is almost certainly the most full-featured of what you will find in the marketplace.

Perhaps by including "grid" in your post you have confused the issue. From the thread so far, I think you want: - a visual component which has Excel I/O capabilities - in particular, the ability to have the cell linked to an object of some sort. Since I do not know the answer myself, does Excel support the attached object? Or is that simply something you need in your UI? If the latter, then you may find looking at TMS FlexCel useful. It is a very capable Excel interface I have used for several years. I think you will find you need a hybrid solution to meet your requirements.

Read this, if you haven't: http://dunit.sourceforge.net/README.html If that doesn't help, I will root around to see whether I have something from old work that I could share.

Have you looked at this? https://delphiprogrammingdiary.blogspot.com/2018/09/unit-testing-by-using-dunit-in-delphi.html DUnit was the first unit test base for Delphi. DUnitX came later, and I think you will find the articles on DUnit are a simpler starting point than those for DUnitX. Nothing wrong with DUnitX, it's just that many writers will likely assume you already use DUnit.

The key phrase being "valid compiling." And even that is not without limit. In a large application, when the Unit Dependency Cycles (UDCs) reach some threshold, the build time begins to increase exponentially. The exponent has been, in my experience, relatively small, so things do not grind immediately to a halt. But even a 3% degradation can't be sustained -- eventually, a build takes minutes to complete. In Delphi, that is pretty shocking. The problem is in how to reduce the UDCs, since they derive in large measure from poor design. Reducing them is a matter of making real design repairs, and that is expensive. But if you think there is a brute force "solution" I would love to hear of it. I can readily imagine ways of obtaining more breathing space: faster CPUs, more compiler threads, more memory available for compilation. But all you get from those is a limited ability to delay the necessary repairs.

Whether it improves compile time depends on just how many Unit Dependency Cycles you have. In a large legacy project, it can be a very large number, and reducing that number can greatly help with build time. Also not, "build" not "compile".

Yes, and a euphemism for fragile.