{"id":1372,"date":"2013-04-23T11:12:36","date_gmt":"2013-04-22T23:12:36","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=1372"},"modified":"2013-04-23T11:12:36","modified_gmt":"2013-04-22T23:12:36","slug":"dproj-woes","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/1372\/","title":{"rendered":"DPROJ Woes"},"content":{"rendered":"<span class=\"rt-reading-time\" style=\"display: block;\"><span class=\"rt-label rt-prefix\">[Estimated Reading Time: <\/span> <span class=\"rt-time\">4<\/span> <span class=\"rt-label rt-postfix\">minutes]<\/span><\/span><p>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 unit to the <strong>uses<\/strong> list of an existing unit in the same project.  It was at that point that things started to go awry.<br \/>\n<!--more--><br \/>\nWhen it encountered the new unit in the uses list of the referencing unit, it complained that the file did not exist.<\/p>\n<p>This was strange because I was sure that the unit was in the DPR uses list and so if there was any problem with it not existing this should have been encountered before.  So I double checked, and sure enough the unit was in the DPR uses list.<\/p>\n<p>The first thing I always check when I get spurious errors involving unit references is my project search path and the possibility that I might have some old DCU&#8217;s lurking in places that they should not be.<\/p>\n<p>So I checked this and &#8211; as I thought, this being a new unit &#8211; this was not the problem.  There were no DCU&#8217;s or old copies of PAS files where there shouldn&#8217;t be (no duplicates etc) and they were all up to date (full build&#8217;s were indeed building fresh new DCU&#8217;s).  But, to be doubly sure I deleted all history files and all DCU&#8217;s anyway.<\/p>\n<p>Nothing changed.<\/p>\n<p>But, at least duplicate\/old DCUs were eliminated as a possibility.<\/p>\n<p>Next, I removed the unit from the unit uses list, and to make doubly sure that it was still being compiled by the project (by virtue of it being referenced in the DPR uses list) I added some code to the initialization section of the new unit, to throw up a message box at runtime, just so I could be certain that it was being compiled into the project.<\/p>\n<p>Sure enough, the project compiled successfully and when it was run the message was presented as expected.  Clearly this unit that the compiler was complaining did not exist not only did exist but was compiling without a hitch.<\/p>\n<p>So, thinking that whatever SNAFU had occurred had perhaps now resolved itself somehow, I added the unit back to the other unit uses list:<\/p>\n<blockquote><p>&#8220;ERROR: File does not exist&#8221;<\/p><\/blockquote>\n<p>Aaagh!  Ok, so what next ?<\/p>\n<p>Well, the unit name was a dotted style name, a convention that I have embraced since Delphi 7 and though it has caused the occasional problem it has generally been a sound strategy.  But in this case, there was a part of the unit name that might &#8211; at the edge of reason &#8211; conceivably cause some problem.  The unit name was <strong>&#8220;<...>.Directory.Interfaces&#8221;<\/strong>.<\/p>\n<p>The <strong><...><\/strong> part was common to a large number of other units in the same project and since this had not been a problem up to now I had no reason to think they might be involved in this case.  Similarly <strong>&#8220;Interfaces&#8221;<\/strong> was part of a number of other unit names, with no problems to date.<\/p>\n<p><strong>&#8220;Directory&#8221;<\/strong>, on the other hand, was a new addition to the lexicon of unit name components.  Even so, I had established that this was not causing problems in the <em>DPR<\/em> <strong>uses<\/strong> list so I could not envisage why it would be an issue in a <em>unit<\/em> <strong>uses<\/strong> list.<\/p>\n<p>But, the first rule of problem solving:  Eliminate the improbable.<\/p>\n<p>So I went back to the beginning.  I removed all references to my new unit and created another new unit with a simple, plain name: <strong>&#8220;Foo&#8221;<\/strong>.  A true classic.  \ud83d\ude42<\/p>\n<p>Everything went as before.  No problem when compiling this with a reference in the DPR uses list but as soon as I added it to the other unit involved:<\/p>\n<blockquote><p>&#8220;ERROR: File does not exist&#8221;<\/p><\/blockquote>\n<p>This was getting ridiculous.<\/p>\n<p>OK, so remove the reference from this unit and add it to some other arbitrary unit instead:<\/p>\n<blockquote><p>&#8220;ERROR: File does not exist&#8221;<\/p><\/blockquote>\n<p>At this point I decided that my entire Delphi installation might have some deeper issues and the prospect of having to re-create my entire development environment began to lurk ominously in the shadows.<\/p>\n<p>One last thing occurred to me to try: the <strong>DPROJ<\/strong> file.<\/p>\n<p>I knew that it contained information about the project contents because this was the place where &#8211; among other things &#8211; the order of units in the <strong>Project Manager\/Explorer<\/strong> was maintained.<\/p>\n<p>But I also knew that aside from compiler and other project settings, the DPR was still the definitive reference for the project contents &#8211; or should be.  Fortunately, the project had no particular specific options set.  In particular, the search path referenced only a couple of 3rd party source trees (Indy, FastMM) which could easily be restored.<\/p>\n<p>So I simply deleted the DPROJ.  With interesting results.<\/p>\n<p>Suddenly my project would not compile at all since it transpired that I had several units missing from my DPR uses list.  These were not units that were previously on the project path because these were units that were part of the project&#8217;s own source tree which was not previously on the project path at all.<\/p>\n<p>Equally I had already deleted all the project DCU&#8217;s so it couldn&#8217;t have been that the compiler had previously been picking up old DCU&#8217;s before now.  The only thing that had changed was that the DPROJ had been deleted and now recreated from scratch (by the IDE).<\/p>\n<p>Once I dealt with the missing units and had a compiling project once more, I added my new unit back in to the <strong>DPR<\/strong> and <strong>unit<\/strong> <strong>uses<\/strong> lists as required and hey presto.  Everything was fine once more.<\/p>\n<p>The lesson I learned from all this:<\/p>\n<p><em>When experiencing perplexing and apparently impossible errors involving unit referencing in a Delphi project, investigate the possibility of a corrupt or damaged DPROJ before wasting time on other causes that will consume more time to explore.<\/em><\/p>\n<p>I only wish I had kept a copy of the DPROJ so that I might have conducted a post-mortem on the damaged\/corrupted file which might have shed some light on what had happened.<\/p>\n","protected":false},"excerpt":{"rendered":"<p><span class=\"rt-reading-time\" style=\"display: block;\"><span class=\"rt-label rt-prefix\">[Estimated Reading Time: <\/span> <span class=\"rt-time\">4<\/span> <span class=\"rt-label rt-postfix\">minutes]<\/span><\/span> 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 unit to the uses list [&hellip;]<\/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":[200,199],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-m8","jetpack_sharing_enabled":true,"jetpack-related-posts":[{"id":1397,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1397\/","url_meta":{"origin":1372,"position":0},"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 &quot;Delphi&quot;","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1945,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1945\/","url_meta":{"origin":1372,"position":1},"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 &quot;Delphi&quot;","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":1300,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1300\/","url_meta":{"origin":1372,"position":2},"title":"What&#8217;s in a Name(space) ?","date":"28 Nov 2012","format":false,"excerpt":"The ever evolving DWScript project continues to advance the Pascal language at an impressive pace. Just today it was announced that this scripting version of Pascal now has \"namespace\" support. When I first read the details of the implementation, my initial reaction was that it \"felt a bit backwards\". The\u2026","rel":"","context":"In &quot;Delphi&quot;","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1954,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1954\/","url_meta":{"origin":1372,"position":3},"title":"Hands Off My Application! (Another DPR Trick)","date":"18 Oct 2013","format":false,"excerpt":"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\u2026","rel":"","context":"In &quot;Delphi&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Screen-Shot-2013-10-18-at-09.01.47.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":2144,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2144\/","url_meta":{"origin":1372,"position":4},"title":"Smoketest 1.0 &#8211; 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 &quot;Delphi&quot;","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":3019,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/3019\/","url_meta":{"origin":1372,"position":5},"title":"What&#8217;s in a Name[space] ?","date":"29 Oct 2019","format":false,"excerpt":"A recap of unit aliases and how they relate to namespace prefixes as a prelude to a more interesting examination of Scope Elevation.","rel":"","context":"In &quot;Delphi&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/niklaus-wirth-edit.jpg?fit=934%2C362&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]}],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/1372"}],"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=1372"}],"version-history":[{"count":5,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/1372\/revisions"}],"predecessor-version":[{"id":1377,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/1372\/revisions\/1377"}],"wp:attachment":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media?parent=1372"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/categories?post=1372"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/tags?post=1372"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}