How to prevent Delphi modifying its DPR (project source) unexpectedly

7
votes

To maintain its project, Delphi sometimes adds or removes stuff from the DPR file (project source). I quite like to format my stuff in the DPR as if it is an ordinary unit, for example to group together the 'used' frame references and project source files. I make copies of it and can go back when this happens but every so often, I'll notice that the DPR has had all its source file references smashed into a single block.

Anyone else suffer from this? Is there any way of preventing this from happening (other than a read-only file). Thanks

4
delphiproject
Revision control is the solution. - David Heffernan
@David: More a workaround than a solution. - Toto
@Toto Since Brian is manually making copies of this file, I'd say using some revision control would solve a lot, but your point is valid! - David Heffernan
@Mikey The IDE regularly breaks my .dpr file. My .dpr file has a conditional in its uses clause. Also some of my .dpr files are non-standard in between the begin and end. So no, the developer is not in control of the IDE. - David Heffernan
@Mikey: No - the IDE is giving a not so subtle hint that the design of its project managing could be better. :-) - Uli Gerhardt

4 Answers

9
votes

What I do for most of my projects is to have these 2 files:

  1. MyProgram.dpr
  2. MyProgramUnit.pas

MyProgramUnit has a public method Main that contains all the logic from the .dpr (including any conditional defines)

MyProgram just calls Main.

Edit 1:

You can put uses lists in MyProgramUnit.pas, but they don't automatically become part of your project. That might or might not be an issue, it depends if you like having Delphi finding units in a search path, or add files to your project to make them visible.

What you can do, is to document the uses-lists in MyProgramUnit.pas and group them by cause. This is what I normally do in most units anyway, not only in the main unit.

Edit 2:

Don't go the {$I MyIncludeFile.inc} way.
Delphi - especially the IDE - is bad with include files. Code Completion, etc, fail at irregular places.

I've been heavy on include files in the past; not so any more. I even stopped using them for defines, and moved from {$IFDEF define} ... {$ENDIF} towards {$IF Constant1 >= Constant2} ... {$IFEND}.

7
votes

The .dpr is a normal Delphi file, alright, but once it is opened in the IDE, it is more or less "owned" by the IDE. There is no way to stop the IDE from adding or removing code from it, when the IDE thinks that is necessary (e.g. when you added a unit, changed some settings, etc.). That can also mean it reformats parts of the code.

If you want "immutable" code, put it in a unit.

1
votes

I think Rudy's got this one right.

IMO, it's wiser to keep hands off the dpr uses block in the editor - the project manager is designed to do that - by hand you're liable to corrupt your project settings and introduce some hard to track down bugs in large projects. As for formatting, in Delphi XE there is autoformat that will do your whole project and is configurable.

I often edit the 'program' section of the dpr (that also requires some knowledge and caution) but not the uses block.

One additional point: some of what happens in the dpr can be controlled from your project options settings.

HTH

0
votes

Personally I make a copy of my uses clause in a giant comment at end of my DPR file. So when Delphi modifies it, I "restore" it from the comment. Of Course I have to be cautious of maintaining my "uses comment" up to date.

Note : I'm using external tools that scan the project file so I cannot use the "external unit" approach, although it seems the cleanest solution.