Mega Code Archive

Dumb VCL

Title: Dumb VCL Question: Component writing tips Answer: As most of us I think the VCL is perhaps the greatest framework for RAD, however as many I have faced poorly written components in the VCL and have come up with some suggestions on how components are being written, and why sometimes it seems to me poor desing A) The case of the imcomprehensible property: Some component writers go to great lengths to ensure that they write a property whose name means nothing and/or is so big that you actually need to get used to it to know what it does. B) The unnecessary resource inclusion: Yes visual components must have some sort of bitmaps, cursors, etc. however this goes to the final application, although executable sizes have long gone to history, think of it do you need in your executable 15 bitmaps when you are really using just one. Common examples of this are in borlands very own TBitBtn wich links every bitmap even if the kind is set to bkCustom, InfoPower wich links every form in the package when you put a wwDBGrid and/or any component (Yes this is true get a resource viewer and check what is compiled into your exe, you may use delphi's own ResExplr Demo) C) The bunch of units: This happens frequently sometimes you get a component wich links a bunch of units in your code, although the linker manages just to pick the code necessary to make the program work that bunch of units sometimes just include one method per unit, and are badly grouped (you see 10 units handling color functions instead of just one with all the functions) D) The 10000 lines unit: While having a bunch of units is bad when customizing code and you are faced with a unit with several lines of code with no code documentation you wind up sticking to the default behavior, and these kind of units most of the time could have been splitted into a couple of units. I think the best example of a huge unit is any developer express component they tend to make units as long as 16000 lines but due to documentation and trial and failure you get an idea of what is going on. Why I mention this? quite easy, most of the time we just need to make a subclass to customize behavior of a object, but if what you need is hidden deep within a bunch of classless methods (say change functionA to FunctionB to obtain behavior B instead of subclassing whole classA to classB). E) Poor documentation: This one is quite common with several third party VCL, while most of us are developers some sort of documentation is needed, samples are a bunch of components available on torry's with no source. F) Poor property grouping: This one is quite common, you see there are 10 color properties in x component while this is not a problem if the properties have different letters they would wind up in different places, the best solution could be a TPersistent subclass wich groups all the properties, or if you are to take advantage of latest Object Pascal features read on property grouping for Delphi version 5 and above. G) Reinventing the wheel: Sometimes component writers go to great lengths to write their components, including creating functions already in the VCL, sometimes it is a must (for example if you want to use freeandnil procedure in a pre-D5 compiler) but if possible should be avoided. Well thats it for now