Bill Meyer

In 10.3, I just created a new app, placed a TFlowPanel on the form, then dropped in a few buttons. I selected a button, and in the ObjectInspector, I find ControlIndex. On Button1, it is zero. I change it to 1, and Button1 now moves to the right of Button2.

Don't they have a ControlIndex property added at the bottom of the Object Inspector? If they do, that's the way to control the ordering.

Agreed! And CloneVDI is indispensable.

I understand. I have been pursuing a number of possibilities, but ultimately, someone else will make the call about how we address the problem. The mass of modules and the tight coupling in the project obviously need to be corrected, but that is a long path, and the issue, as always in a commercial enterprise, will be decided by managers whose appreciation of the factors may be less complete than one might wish.

OK, I thought you might know,as you raised the idea. I haven't worried about resources in a very long time, and will have to do some research, as well, to learn whether there is a limit. Taking out "some forms" isn't really an answer, for a number of reasons, chiefly that there is too much coupling to make this a trivial activity. Adding in a unit -- not even a form -- is enough to trigger the problem. Testing is, as you would guess, problematic. And all the worse for there being too much code on forms, which is another characteristic I simply identify now as Delphi legacy style.

Interesting thought. How does one assess the size of resource in an entire project? As to the how: Years of development, a complex set of requirements, and certainly a failure to consolidate where possible.

Before adding a module, the units all execute initialization with no problem. After adding a unit, execution does not reach that point. And the debugger is useless.

Another good thought, but I re-saved with Notepad++ set for CR/LF endings. No change.

A worthy notion, but a relatively short time ago I wrote my own tool to find all of the (52, at the time) binary DFMs and convert them. So no binaries present in the mix.

We do have over 2,000 forms and units in the app.

No. And also have done a comparison of the map files of good and bad. Nothing odd there, either.

No, that was checked. But also, adding a new unit, as in File, New, Unit, and putting in it no code, also provokes the problem.

Well, that would be very interesting. I would be happy to do some testing.

Yes, I could do that. I assume, however, that you are implementing for v14, not for earlier versions? Most of my work is in D2007, where I have literally thousands of such uses clauses to work with.

I have been pondering the problem myself, as I want to reorder the uses clauses in a large number of units. The variations imposed over the years by thoughtless developers make the task a good deal more challenging than it ought to be: uses OneUnit, Another, MyThird , Fourth, {NoLongerUsed,} StillMore {Why here?}, Last ; Conditionals obviously add to the fun. Moreover, I want to organize so that Delphi library modules are in the first grouping, then third-party, and last, units of the application. And then, of course, to provide for walking the file tree and applying changes to each application module found in the map file.

A further thought: Perhaps a command to normalize without sorting class(es)? Resorting the classes would make for some source control issues in future. The normalization of signatures, though it would obviously affect source control, would be relatively minor, by comparison.

Oops, my bad! I was doing other things, and unable to confirm before I write that. And then began to think I was wrong.

Sort the class(es). That will apply the cleaning to all members (I think!). But look first at the sorting options. If you are using source control, think carefully before you leap. 😉

Confirmed here, though I did also see Ctrl-E fail to open the edit dialog in D2007 today. I am assuming it is contextual, as I do routinely use it in D2007.

Actually, it does, or did, convert existing. Just did it in D2007 and in XE7. Will try it later in 10.2.3, to see whether it fails. Obviously, I am not using v14 in those older IDEs. Update: Works as I described in Delphi 10.3.1 with MMX 14.0.5. I do not have 10.2.3 available here at the moment.

Which version are you in? I have seen modules in D2007 IDE which I am unable to Ctrl-E edit. Try creating a small project with a routine which needs to be un-wrapped. If it works, then there is something in the project you are testing now which is giving the IDE fits.

Should only need to be in the scope, in other words, the cursor in the signature, or anywhere in the method you wish to affect. (Sorry, I cropped that image a bit. It is the Pascal Editing page.)

If you use MMX, with right margin sent to some high value, then edit the routine: Ctrl-E, Enter, the result will be to put the signature all on one line. It will do so in both the interface and implementation sections, in one action.

Agreed. And it can be sorely tempting in that legacy code, especially in a class which is painfully large and ought to be refactored. But working in a group, it would be pretty hostile to apply the sort. 😉

In my own code, and in code which I inherit from other sources, I like to use MMX to sort classes. Unfortunately, I work with a good deal of legacy code which is in source control, and applying class sorting would wreak havoc there.