{"id":1954,"date":"2013-10-18T08:24:42","date_gmt":"2013-10-17T20:24:42","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=1954"},"modified":"2013-10-18T11:17:00","modified_gmt":"2013-10-17T23:17:00","slug":"hands-off-my-application-another-dpr-trick","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/1954\/","title":{"rendered":"Hands Off My Application! (Another DPR Trick)"},"content":{"rendered":"[Estimated Reading Time: <\/span> 3<\/span> minutes]<\/span><\/span>

In a comment on my previous post, David Heffernan noted that the IDE messes around with other parts of the application DPR<\/a> 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<\/strong> itself !<\/p>\n

Fortunately there is a simple way to avoid that also.<\/p>\n

<\/p>\n

First, Recognise the Problem<\/h2>\n

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).<\/p>\n

Create a new VCL Forms application and View Project Source (the DPR). You should see something like this:<\/p>\n

\r\nprogram Project1;\r\n\r\nuses\r\n  Forms,\r\n  Unit1 in 'Unit1.pas' {Form1};\r\n\r\n{$R *.res}\r\n\r\nbegin\r\n  Application.Initialize;\r\n  Application.MainFormOnTaskbar := True;\r\n  Application.CreateForm(TForm1, Form1);\r\n  Application.Run;\r\nend.\r\n<\/pre>\n
Now open the Project Options<\/strong> dialog, select Application<\/strong> settings and enter something as the Application Title<\/strong>:<\/p>\n
\"Setting<\/a>
Setting the Application Title<\/figcaption><\/figure>\n
Press OK<\/p>\n
Before your very eyes the project DPR will change to:<\/p>\n
\r\nprogram Project1;\r\n\r\nuses\r\n  Forms,\r\n  Unit1 in 'Unit1.pas' {Form1};\r\n\r\n{$R *.res}\r\n\r\nbegin\r\n  Application.Initialize;\r\n  Application.MainFormOnTaskbar := True;\r\n  Application.Title := 'Right Honourable Application';\r\n  Application.CreateForm(TForm1, Form1);\r\n  Application.Run;\r\nend.\r\n<\/pre>\n
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<\/strong> and going back to the Project Options<\/strong>.<\/p>\n
The Application Title<\/strong> is no longer set!<\/em><\/p>\n
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 !<\/p>\n
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<\/strong> variable (from the Forms unit).<\/p>\n
If You Can’t Beat Them, Hide<\/h2>\n
Obviously you can put your own code in this begin\/end<\/strong> area.  Very often you have to, to perform initialisation or checks before launching into your UI.<\/p>\n
But precisely because you can<\/em> add code the IDE does do it’s best to identify only those parts in that code which it feels it should<\/em> 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.<\/p>\n
So all we have to do is remove those markers.<\/p>\n
We can do this very simply by declaring our own variable to use in place of Application<\/strong>:<\/p>\n
\r\nvar\r\n  app: TApplication;\r\nbegin\r\n  app := Application;\r\n\r\n  app.Initialize;\r\n  app.MainFormOnTaskbar := True;\r\n  app.CreateForm(TForm1, Form1);\r\n  app.Run;\r\nend.\r\n<\/pre>\n
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<\/strong> and end<\/strong>.  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.<\/p>\n
It does mean that you have to avoid using certain IDE features.<\/p>\n
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<\/em>“.  But more importantly, it won’t try to make any changes in the DPR either<\/em>!<\/p>\n
As I mentioned, the other key area that this “breaks” is the Main Form<\/strong> and Auto-Create Forms list<\/strong> in the project options.<\/p>\n
With Great Power Comes Great Responsibility<\/h2>\n
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.  \ud83d\ude42<\/p>\n
In applications where you don’t need any bespoke changes in the DPR code you can of course just leave things as they are.<\/p>\n","protected":false},"excerpt":{"rendered":"
[Estimated Reading Time: <\/span> 3<\/span> minutes]<\/span><\/span> 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 […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":[]},"categories":[4],"tags":[292,246],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-vw","jetpack_sharing_enabled":true,"jetpack-related-posts":[{"id":1945,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1945\/","url_meta":{"origin":1954,"position":0},"title":"Unit Aliases and Build Configurations","date":"17 Oct 2013","format":false,"excerpt":"Over on stackoverflow, Ann Gossard had a question about using an $ifdef in the project (DPR) uses list to use one unit in preference over another, specifically in debug builds. In this situation, it immediately occurred to me that unit aliases might be creatively deployed. What follows is a slightly\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Screen-Shot-2013-10-17-at-15.25.51.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":1985,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1985\/","url_meta":{"origin":1954,"position":1},"title":"Build Automation With Train","date":"29 Oct 2013","format":false,"excerpt":"A comment from Kevin P brought a build automation tool to my attention this evening, called Train. Train is a JavaScript based build automation tool from a little company called RemObjects. It is written in Oxygene but the API provides specific support for Delphi. It's an open source project and\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Screen-Shot-2013-10-29-at-23.36.22-.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":1397,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1397\/","url_meta":{"origin":1954,"position":2},"title":"Qualified Enum Reference That Fails to Compile in XE4 (and rightly so)","date":"01 May 2013","format":false,"excerpt":"Running through some of my code last night, putting them through the new XE4 compiler, threw up a real oddity: Some code that used to compile just fine, which no longer compiles in XE4 and which should not have compiled before! It's an odd one, because the code previously compiled\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1372,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1372\/","url_meta":{"origin":1954,"position":3},"title":"DPROJ Woes","date":"23 Apr 2013","format":false,"excerpt":"I spent the best part of half a day last week trying to get to the bottom of a very strange issue on a project I was working on. I had just created a new unit in the project and had reached a point where I needed to add that\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":2144,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2144\/","url_meta":{"origin":1954,"position":4},"title":"Smoketest 1.0 – Release and Be Damned!","date":"14 Nov 2013","format":false,"excerpt":"As I have been promising for some time (quite literally 5 years (!), I am ashamed to admit) I am finally unclenching and releasing the Smoketest framework into the wild, ready or not. The code is published and will continue to be updated in a github repository. Documentation is still\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Screen-Shot-2013-11-14-at-19.51.57-.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":2878,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2878\/","url_meta":{"origin":1954,"position":5},"title":"Azure DevOps – Template for Builds + Running Tests and Capturing Results","date":"12 Sep 2019","format":false,"excerpt":"A more complete build script, re-usable in the form of a template, that caters for different Delphi versions, combined with a demonstration of running unit tests and capturing results for reporting and analysis in Azure DevOps Pipelines.","rel":"","context":"In "automation"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Screen-Shot-2019-09-12-at-14.25.20.jpg?fit=386%2C386&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]}],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/1954"}],"collection":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/comments?post=1954"}],"version-history":[{"count":7,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/1954\/revisions"}],"predecessor-version":[{"id":1963,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/1954\/revisions\/1963"}],"wp:attachment":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media?parent=1954"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/categories?post=1954"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/tags?post=1954"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}