[Estimated Reading Time: 3 minutes]

In a comment on my previous post, David Heffernan noted that the IDE messes around with other parts of the application DPR in addition to the uses list. He is right. Another area that the IDE likes to muck about with is the code in the DPR begin .. end itself !

Fortunately there is a simple way to avoid that also.

First, Recognise the Problem

Let’s see just one of the things that IDE does in this area (version used for this exercise: Delphi 2010. Steps may vary slightly in any different version but should be easy enough to follow).

Create a new VCL Forms application and View Project Source (the DPR). You should see something like this:

program Project1;

uses
  Forms,
  Unit1 in 'Unit1.pas' {Form1};

{$R *.res}

begin
  Application.Initialize;
  Application.MainFormOnTaskbar := True;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

Now open the Project Options dialog, select Application settings and enter something as the Application Title:

Setting the Application Title
Setting the Application Title

Press OK

Before your very eyes the project DPR will change to:

program Project1;

uses
  Forms,
  Unit1 in 'Unit1.pas' {Form1};

{$R *.res}

begin
  Application.Initialize;
  Application.MainFormOnTaskbar := True;
  Application.Title := 'Right Honourable Application';
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

This is just the first example of where the IDE re-writes your DPR code. There are others (changing the Main Form and/or the list of auto-created forms, for example), but many if not all of them can be defeated by one simple trick. A clue to that trick can be found by removing the line from the DPR that sets Application.Title and going back to the Project Options.

The Application Title is no longer set!

Not only does the IDE apply these settings by re-writing your DPR code, it actually seems to get the current setting by reading the code too !

For these features, the IDE relies on being able to recognise certain things in the code of your DPR, driven by the “boiler-plate” code created by the project wizards that it expects to find. In this case, code that uses the Application variable (from the Forms unit).

If You Can’t Beat Them, Hide

Obviously you can put your own code in this begin/end area. Very often you have to, to perform initialisation or checks before launching into your UI.

But precisely because you can add code the IDE does do it’s best to identify only those parts in that code which it feels it should be able to modify. If the IDE cannot find the required “markers” that identify the pieces that the IDE wishes to modify then rather than risk doing damage it simply keeps itself to itself.

So all we have to do is remove those markers.

We can do this very simply by declaring our own variable to use in place of Application:

var
  app: TApplication;
begin
  app := Application;

  app.Initialize;
  app.MainFormOnTaskbar := True;
  app.CreateForm(TForm1, Form1);
  app.Run;
end.

Once you’ve done this I don’t think the IDE will ever trouble your DPR again, at least not the parts between the begin and end. Which is to say that in almost 20 years of Delphi, after making such a change to the DPR I don’t recall a single instance of the IDE ever trying to make unwelcome changes in this area.

It does mean that you have to avoid using certain IDE features.

They either simply won’t work or will complain. Try changing the application title now and Delphi 2010 will complain that it cannot find a valid “Application.CreateForm“. But more importantly, it won’t try to make any changes in the DPR either!

As I mentioned, the other key area that this “breaks” is the Main Form and Auto-Create Forms list in the project options.

With Great Power Comes Great Responsibility

By denying the IDE the capability to manage your DPR code you have to take on the responsibility of managing things yourself. But then, since the whole point is to avoid problems that the IDE management of this code can cause, you wouldn’t have wanted to continue using them anyway. 🙂

In applications where you don’t need any bespoke changes in the DPR code you can of course just leave things as they are.

6 thoughts on “Hands Off My Application! (Another DPR Trick)”

  1. One way it still messes with you is if you ever try to IFDEF the uses clauses in your dpr. I learned NOT to do that!

  2. Never occurred to me and there is the odd project were I wanted the IDE wouldn’t mess with things. Now I know how to stop it. Thanks!

Comments are closed.