Jump to content

Bill Meyer

Members
  • Content Count

    121
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by Bill Meyer

  1. 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.
  2. Bill Meyer

    Bad build a mystery

    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. Bill Meyer

    Bad build a mystery

    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.
  4. Bill Meyer

    Bad build a mystery

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

    Bad build a mystery

    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.
  6. Bill Meyer

    Bad build a mystery

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

    Bad build a mystery

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

    Bad build a mystery

    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.
  9. Bill Meyer

    On The Design Of Uses Clauses

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

    On The Design Of Uses Clauses

    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.
  11. Bill Meyer

    On The Design Of Uses Clauses

    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.
  12. Bill Meyer

    Can GExperts format multiline method definition to single line?

    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.
  13. Bill Meyer

    Can GExperts format multiline method definition to single line?

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

    Can GExperts format multiline method definition to single line?

    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. 😉
  15. Bill Meyer

    Can GExperts format multiline method definition to single line?

    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.
  16. Bill Meyer

    Can GExperts format multiline method definition to single line?

    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.
  17. Bill Meyer

    Can GExperts format multiline method definition to single line?

    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.
  18. Bill Meyer

    Can GExperts format multiline method definition to single line?

    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.)
  19. Bill Meyer

    Can GExperts format multiline method definition to single line?

    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.
  20. Bill Meyer

    How do you organize units, forms?

    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. Bill Meyer

    How do you organize units, forms?

    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.
  22. Bill Meyer

    Best delphi so far?

    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.
  23. Bill Meyer

    Best delphi so far?

    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.
  24. Bill Meyer

    Best delphi so far?

    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.
  25. Bill Meyer

    Best delphi so far?

    There is little question that they are a design weakness. In fact, that is a gross understatement. The apparent need for such cycles is a clear indicator that some units contain things which should be separated. Often a class has become a Swiss Army knife, providing too much functionality, marginally related. That's bad design, and substantial refactoring may be needed. The same pathology can be introduced, however, in simple procedural modules, where once again, too many loosely related elements are kept together. Unit dependency cycles: are multiplicative, so should be eliminated as early as possible exact a penalty in build times, and in one major project, I have seen exponential increase in build times as new modules are added, using the old render code analysis difficult, at best are often difficult to remove, as they usually require redesign I have observed that unit dependency cycles are often commonplace in legacy code projects. Further challenges lurk where such tangled modules have been recycled into new projects.
×