{"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_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[4],"tags":[292,246],"class_list":["post-1954","post","type-post","status-publish","format-standard","hentry","category-delphi","tag-delphi","tag-tips-and-tricks"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-vw","jetpack_sharing_enabled":true,"jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/1954","targetHints":{"allow":["GET"]}}],"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}]}}