Bill Meyer

19 hours ago, David Heffernan said:

I've no idea, never needed to try. Not even sure that there is a limit, or what it is. But if you take out some other forms and the build succeeds then that is very strong evidence. 

 

How do you even begin to test 2000 forms? I just can't get me head around this at all. 

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.

6 hours ago, David Heffernan said:

Is it possible that you have reached the upper size limit for resources? Try removing some other forms and see if the project builds. That would strengthen this hypothesis. 

 

I can't begin to understand how you end up with 2000 forms in a single executable. 

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.

3 hours ago, Darian Miller said:

 

The only thing left for me to suggest is to step through each and every initialization section until you find one that blows chunks.  I'd do a debug build (without system DCUs first) and then step through (F7) until you hit the main form display or you get an exception.

 

I love a good mystery!   Sorry, I know it's much more fun on this end...

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.

8 hours ago, PeterBelow said:

Did you check the dpr file for bad line ends (only cr or only lf)? What happend to me some time ago was that the IDE inserted a new form unit name in the DPR file smack in the middle of an existing one, which of course did not build anymore and resulted in some weird error messages (no IDE crash, though). I found out that the file had become corrupted, with  mix of linebreak styles. I never found out how that happended...

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

13 minutes ago, Darian Miller said:

I experienced a similar problem a while ago.  From what I recall, it was a bad binary DFM which had to be isolated/corrected.  For some reason, that experience came back to me after seeing your response.  (Too many bad memories that have been suppressed!)  

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.

3 minutes ago, Darian Miller said:

Just spit balling here - but add a new unit, save the project and do a file compare of the DPR + DPROJ files... anything odd? 

 

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

24 minutes ago, Uwe Raabe said:

Could it be that the new form was auto-created in the dpr when it should not?

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.

I am working on a large legacy project, and recently encountered an unexpected failure. We added a new form, did a full build, and ran the program in debug. It showed some activity, but returned to the IDE, as though the app had shut down, and it never reached the splash screen.

Running the executable outside the debugger, it reports an AV, then when you close, it reports runtime error 217. If EurekaLog is enabled, no elf file is produced. Some searching online shows that the error in question occurs before exception handling is set up.

Removing the newly added form, the app builds and runs as normal.

Adding a new unit, with no code, also provokes the total failure. 

I am at a loss to know how to discover the real problem. Any thoughts would be welcome.

3 minutes ago, Uwe Raabe said:

I am referring to a command line tool.

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

10 minutes ago, Uwe Raabe said:

Are you interested 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. 

3 hours ago, Uwe Raabe said:

Well, the actual problem here are the conditionals around the uses keyword and the closing semicolon. The rest inside is fine.

 

This version is handled without problems:

{$if defined(DEBUG) or defined(DEBUG_SPECIAL)}
uses
{$IFDEF DEBUG}
  dialogs
{$ENDIF}
//<some comment about the following ifdef>
{$IFDEF DEBUG_SPECIAL}
  mmsystem, // timeGetTime()
  messages
{$ENDIF}
  ;
{$ifend} 

 

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. 

7 hours ago, Uwe Raabe said:

I filed a feature request for a new sort option to normalize the code while sorting.

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.

4 hours ago, Uwe Raabe said:

AFAIK, that won't work.

 

As an alternative you can use the built in Delphi code format feature with <Ctrl>-D.

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

53 minutes ago, Mike Torrettinni said:

It works! I closed and re-opened Delphi, now CTRL+E shows Edit procedure dialog, before it didn't. And just pressing Enter, it reformats definition for that method.

Great, thanks!

 

Any way to reformat the whole existing unit at once?

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. 😉

Just now, Uwe Raabe said:

It does. When the cursor is somewhere in that method (declaration or implementation) pressing <Ctrl>-E followed by <Enter> to open, close and accept that dialog will unwrap these lines.

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.

48 minutes ago, Mike Torrettinni said:

Aha, it works on new methods - adding new method will be a 1 line definition, when double clicking method in Object inspector.

It doesn't convert old/existing methods.

 

I have D 10.2.3 and MMX 14.0.5 build 2276

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.

1 minute ago, Mike Torrettinni said:

Wrap margin is set to 500. but still it doesn't work - or, I don't know how to use it properly. No matter where my focus is, CTRL+E does not do anything. I even tried selecting the method and CTRL+E and nothing.

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.

21 minutes ago, Mike Torrettinni said:

I do use MMX, well just started. I set right margin high (500). I tried, but I can reproduce the behavior you are describing with CTRL+E, Enter... where exactly should my cursor be to press CTRL+E and then Enter, in code, in MMX?

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.)

5 minutes ago, Mike Torrettinni said:

Can GExperts reformat this:

procedure VirtualStringTree1GetText(Sender: TBaseVirtualTree; Node:
        PVirtualNode; Column: TColumnIndex; TextType: TVSTTextType; var CellText:
        string);

 

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.

3 minutes ago, Sherlock said:

Amen! Anyway, sorting is just something that pleases the eyes. I only keep the methods sorted within their classes. Anything else I find via Ctrl+f or Shift+Alt+s.

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. 😉

21 hours ago, Mike Torrettinni said:

I just started looking into MMX for cyclic usage, not for anything else. I only use Structure view for Forms, not for code... interesting, will give it a try. Thanks for the tip!

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.

17 hours ago, Georgge Bakh said:

Again, I didn't stated that it's simple. I know that dealing with broken code is hard.

But it should be a code tools developer problem. Not users.

Refactoring is rarely simple, but it is essential. Redesign can be even more of a challenge in legacy code, as there tends to be a lack of documentation, and often poor naming practices obfuscate the purpose of the code.

I don't see any way that the IDE could be held responsible for performing to overcome the creation of developers. 

17 hours ago, mael said:

When using components or libraries, I think it is poor practice to include them in your projects, since they are shared files. They should be compiled independently to ensure you use the same version and state everywhere. All major Delphi components work this way, and you don't include the RTL or VCL units in your projects, either.

 

When placing components on the form, this should work seamlessly, and not require editing project specific library paths (or the IDE should do it automatically).

 

The IDE is just buggy regarding code completion and parsing, to more or less severe degrees depending on the version. This scenario is a very standard one, and should work.

I was not speaking of components or libraries. But all of the units you write for your application should be in the DPR. Relying on the search path does affect the IDE, whether we like it or not.

Yes, there are defects in the IDE with regard to Code Completion and Error Insight, but following lazy practices which can be shown to exacerbate the problem is just foolish.

19 hours ago, Georgge Bakh said:

I didn't say that dependency cycles are a good thing. I trying to avoid them myself. But it is not always possible due to lack of a bigger visibility scope than unit.

But I still think that code tools should not break or slow down with unit dependency cycles.

And I know what I'm talking about as writing pascal code tools is my current pet project.

I think there is never a good reason to tolerate unit dependency cycles; they are a consequence of bad design.

Again, if you do not see why unit dependency cycles should slow the tools, there is much of the internal action of the IDE which you do not appreciate. As Anders Hejlsberg said in the video I cited earlier, "...as soon as you type a character, you have broken the code." That is meant no literally, but in the sense that any new character in a code file provokes rebuilding of parse trees.

It's good that you are getting your feet wet. I have been developing tools to address these issues for the last couple of years, not as a pet project, but a part of my current employment, and I assure you, it is not nearly as simple as you seem to believe.