I just recently tracked down and fixed an error in a module that was compiling fine but causing the Code Completion and Code Parameters IDE features to fail once it had.
I tracked the problem down to a reference to the “WinProcs” unit in the uses clause of a utility unit/file I was including in my project’s main form uses clause. I looked into WinProcs, found out it and its partner WinTypes were both replaced by the “Windows” unit in D2, I then ensured that the Windows unit was referenced, commented out the WinProcs reference [you never know eh :) ], tested the project, noticed that the repair had fixed everything I was having problems with and prepared to move on. Then the questions came.
How is it possible that there are any remaining references to these two units [WinProcs and WinTypes] after them being discontinued with the release of D2 [1996]? That’s a long, long time ago. The logical response is backward compatibility with D1 ... hahaha, logical – I don’t think so, that just can’t be true. Was the penetration of these units that deep? Is there that much code still floating around from that long ago? How many other units have been renamed/replaced in the same time span? In what version – not likely version 1 – they are long forgotten if they were. Not these two.
I’ve got a very popular 3rd party tool intended for D6 and up. A search for WinProcs [and in this case WinTypes] comes up with at least 10 hits.
Why is it that you don’t find the same response to the “... can’t find unit FooBar.dcu” questions that get asked? Why is it with WinProcs and/or WinTypes the response is not “you need to replace them with a reference to Windows” -but- add “WinProcs=Windows; WinTypes=Windows” to the Aliases list of your project? Huh?
Why is it that references to these long dead version 1 units are still popping up and breaking specific IDE features? Why is it that some units with WinProcs and/or WinTypes references will actually even compile and result in these broken IDE features? Why is it that Embarcadero has set it up so that when you create a new project, “WinProcs=Windows; WinTypes=Windows” are automagically added to the Aliases list of your project – now that one is just plain spooky if you really think about it. Conspiracy theories anybody ?? Hahaha.
If you mask a reference to one of these long dead units in an alias is it really fixing anything? Have you ever seen a unit with both WinProcs/WinTypes and Windows in the uses clause ... I have ... recently. What effect does the alias have in that condition? It doesn’t stop the compiler ... believe me.
The usual fix to the problem; “Code Completion and Code Parameters IDE features don’t work.” is, add “WinProcs=Windows; WinTypes=Windows” to the Aliases list of your project? Huh?
I am seriously baffled by these references and how they get treated, but that’s just the way it is I guess – perhaps there’s some interesting history that I still need to dig up … thanks for stopping by,
Dave
You're thinking too hard.
ReplyDelete'The logical response is backward compatibility with D1' - more exactly, backward compatibility with code originally written in D1. This of course doesn't exclude that D6+ third party tool. With a mature, evolving code base, it's almost inevitable there will be holdovers from oldentimes.
'Why is it that Embarcadero has set it up so that when you create a new project, “WinProcs=Windows; WinTypes=Windows” are automagically added' - you answer that question yourself in your very next paragraph. Unit aliases are a project-level setting, not a unit-level one.
I'd really appreciate if the unit aliases were empty by default by now (where now is 2007 for me ;-)). It's fun to get rid of them: Empty the "Unit aliases" field in the project options, save and close the project, reopen it - bamm, the default aliases are back. I finally found a workaround: I wrote a little program that adds a line to each configuration in the dproj file.
ReplyDeleteThe site ate my tag: I meant "...adds a line <DCC_UnitAlias /> to each..."
ReplyDeleteAnd you're lucky, in D2007 not only they are not dead, but like zombie they stick around if you try to delete them. Just switch build configuration and they reappear from hell.
ReplyDelete@Chris yes, the whole thing is almost to the point of exaggeration - your point is well taken, for the magnitude of the issue I was thinking way too hard. It just sort of took on a life of it's own once I got started. I can understand holdovers from old times -but- these units are a hold-over from version 1 ... it seems a bit odd that they've survived that long. Something got a little out of control, I find it all a bit fascinating myself. The problem is still getting masked over.
ReplyDelete@Ulrich ... I'm new to aliasing and can see where it could be of some value where there are unit naming conflicts over time but there is certainly the possibility that it gets used to mask problems that should have been fixed, IMHO, a long, long time ago. Thanks for the dproj file tip.
@Anon ... thanks, I'll keep an eye out for that :)
Unit Aliases are another way for quickly switching from one configuration to another.
ReplyDeleteFor instance using a different memory manager, or Data Access Layer.
You could do this with a truckload of IFDEF and facade classes, but with Unit Aliases you can make this a lot less intrusive.
@wiert, Unit Aliases looks to be a fantastic tool with some very powerful applications ... seems such a shame to waste it on something that should have been stomped out of existence many versions ago.
ReplyDeleteThanks.
Doing a test port of my D2007 project to D2010 I found that the "Find Declaration" and most intellisense functionality wasn't working. After a wild goose chase trying to locate/remove cyclic dependencies, I by chance spotted a post that suggested setting the (missing?) unit aliases “WinProcs=Windows; WinTypes=Windows”, and presto, was fixed. Must make an effort to clean these.
ReplyDelete@Anonymous D2007 automatically added the required Aliases to every project - in fact as has been pointed out in some of the other comments, you have to work very very hard to get rid if it ... not the case [thankfully] in D2010. It's just a hack though, it's only masking the problem - good luck on your plan to eradicate the problem properly.
ReplyDelete