How Can Rendering a project Uncompilable be ‘As Designed’?

I’m sure everyone out there has found themselves modifying the DPR source at some point to add some conditional logic for a clean shutdown for instance if a user cancels out of a Login form, or to add conditional directives to account for differences in the Delphi compiler or VCL.

This happened to me most recently when upgrading from Delphi 2007 to Delphi 2010.  The unit generated from the WSDL of a Web Service I am calling changed with DXE so I added an {$IFDEF} to control which unit was compiled.  Then I added a new unit to my project, and suddenly, DXE would no longer compile my project.  It seems it re-wrote the uses list, overwriting my {$IFDEF} block and was trying to use the D2007 version of the web service code.  This kind of thing has been a problem for as long as I remember, which is back to D7 at least, so I submitted a bug report hoping this might finally be fixed.  Instead, the ticket (96783) was closed with ‘As Designed’.

I’ll admit, I’m a simple country boy who after living in the city for 20 years is still a bit naive.  I consider Delphi to be a testament to good design and for the most part implementation.  It’s longevity in an ever changing IT world is a testament to this IMHO.  I have a hard time imagining Anders Hejlsberg and the other original team members thinking to themselves that it was okay to wipe out developer written code and make a Delphi project uncompilable.  If this was the only example I could provide it wouldn’t be as concerning, but there is also QC #99381 which at least didn’t get dismissed with ‘As Designed’. Can someone explain this to a naive country boy?

10 Responses to “How Can Rendering a project Uncompilable be ‘As Designed’?”

  1. Chris Says:

    Presumably ‘as designed’ in this context should be read as a negative: the DPR was not designed to be editable as a normal unit file. The fact it nevertheless can be to a large extent is a bonus (or so the thought probably goes).

  2. Jolyon Smith Says:

    Well, there is another way to look at it.

    After 20 years this is the first time you’ve run into this issue, which is a pretty good indication of how useful it would be to be able to do what you want.

    Right now it is a PITA, but if it’s taken this long to run into it then it really is a bit of an edge case.

    Could you use a unit alias to resolve this ? i.e. refer to the unit using a common name throughout your code in your unit and DPR uses clauses but have that name mapped to a compiler specific physical unit name in the corresponding project settings ?

    Hmmm, then again, if you had separate DPR’s for different compiler versions then you wouldn’t need an IFDEF in the DPR in the first place, so this probably isn’t going to fly either.

    Maybe just having compiler version specific DPR’s is simply the way to go, but at least a unit alias would avoid having to IFDEF throughout the project.

  3. Uwe Schuster Says:

    The problem with QC 96783 is the way too high type and severity that may have lead to that insensible handling. This is indeed not a bug, but the report could have had handled better. Marking it as dupe of

    Report No: 6294 (RAID: 196766) Status: Open
    Retain {$IFDEF} in DPR uses clause

    would have been the much better option.

    Mark Edington (Embarcadero R&D) two years ago on that topic:
    6294 is in the internal system and is something being considered. I did
    some work in that code for D2010 to fix some bugs but that isn’t an area
    of the product I’m primarily responsible for. I haven’t researched what
    would be involved in addressing this limitation, but I can tell you that
    it bugs me enough to make me want to. ;-)

    Cast those votes. They do count. I did!


    Time to put your +10 votes on 6294.

  4. Nick Sullivan Says:

    I would take the words “this kind of thing has has been a problem … back to D7 at least” from the post as undermining the crux of Jolyon’s comment. Moreover it seems entirely reasonable to expect conditional code in an editable source file to work. If DPR files were read only, or if the compiler specifically didn’t allow the conditional code, or warned against it, or simply coped with it intelligently, the problem would not occur. I agree with the poster that ‘as designed’ is a feeble response. It is equivalent to ‘the design is faulty’.

  5. A. Bouchez Says:

    Like you, I was always disappointed with this .dpr auto-rewrite.
    Modifying the .dpr uses clause may make sense: for instance, if you want to have you .dpr ready for several IDE versions, and want to use FastMM4 in older version of Delphi (may be useful, isn’t it?), you’ll have to add a IFDEF in the .dpr. And the IDE will just erase your FastMM4 reference…
    And it is getting even worse. This time (I speak about XE2), I do not speak about IDE re-writing the .dpr, but about having the IDE background compiler (Error Insight compiler) not able to compile code in the .dpr, whereas the main compiler is perfectly able to do that. See - in short:
    1. You have to put full path of each of your unit in your project uses clause;
    2. Error Insight compiler is not able to compile a class definition in the .dpr;
    3. Error Insight is not able to compile simple valid expressions like var Thread: array[0..3] of integer; Handle: array[0..high(Thread)] of integer; whereas the main compiler does.
    IMHO all IDE compilers shall be able to compile the same source code. Delphi is not only just about RAD development: there are plenty of serious not-RAD projects using it, which are definitively more complex than some simple sample code to compile for a CodeRage demo.

  6. David Heffernan Says:

    I suffer from this too. Exactly the same reasons lead me to do exactly what you do. I think it’s a widespread problem. Talk to any experienced Delphi dev and they will know about the issue.

    As designed means that they don’t want to change the code and are content with its behaviour. Since you can edit the .dpr yourself and use revision control to keep control of the contents, they take the view that you have a good workaround. Presumably they feel that the effort on their part to parse it properly is not commensurate with the return.

  7. LDS Says:

    I’ve this problem since Delphi 1 at least… the wrong idea was to use the .dpr both as the “main” file and the “project management” file. The list of unit used by the project shouldn’t have been there in the first place, but in a separate file. Since they added a separate project file long ago, they should have stopped using the .dpr that way, but didn’t.
    This is also coupled with the nasty habit of keeping some data in the compiled .res file handled by the IDE instead of handling them in a more proper place (like an .rc file).
    All those are Delphi 1 legacy issues, that is pretty incredible they are not removed yet sixteen years later.

  8. Eric Says:

    @LDS: problem with the .dproj is that it contains machine-specific settings, and thus is unsuitable for use in heterogeneous environments, while the .dpr doesn’t.
    Usually when you get a “foreign” project that comes with a .dproj, the first step to take is usually to delete the .dproj and have it recreated from the .dpr…

    And yeah, the .res is just as bad, if not worse. The recently added ability to add custom resources referenced through the .dproj rather than a .rc further adds to the problem rather than solve it.

  9. LDS Says:

    The .dproj is an xml file and Delphi could handle it much better than it does now, even if it has machine specific settings - it just needs better design and development care, and understanding the times of the lone TurboPascal developer are over, moving a project file from machine to machine should be handled better, maybe with some options to “reset” the machine specific parts of it.

  10. Larry Hengen Says:


    I agree completely with your comments. I think it’s time EMB addressed some of this legacy baggage…the motivation for my post.

Leave a Reply