BlogAll Blog Posts | Next Post | Previous Post
Wednesday, June 02, 2010The components of the VCL framework were designed to be highly extensible & customizable. Delphi & C++Builder developers are used to get the desired behavior by modifying properties, using events or when this is not sufficient, to create a descendent class from a standard VCL component and add specific extensions needed in applications. We run in trouble though when some functionality we want to modify or extend is in the private declaration of the VCL component. Sometimes a trick will do, sometimes elaborate workarounds are needed, sometimes we need to rewrite the component from scratch, but the general consencus is that we shouldn't modify the VCL source code.
The same applies in fact to 3rd party VCL components. While we and all other 3rd party VCL component producers try to provide components that are as feature-complete as possible, there are times when a built-in behavior, function or appearance just isn't what is needed in the application. Just as with the VCL, either the desired functionality can be obtained by implementing for example a custom drawing event or creating a descending class. As most 3rd party VCL components, including ours, come with source code, the temptation is high to dive in the source code of the VCL component and quickly add or change some part of the source code. On short term, this is in many cases by far the quickest solution to obtain some functionality needed in an application but on long term, this causes the serious problem that one is stuck with its own branch of the 3rd party VCL components. At this point, each update of the 3rd party VCL component, be it for compatibility with a new Delphi version, updates for a new operating system, updates with fixes or new features means work to do to merge own extensions and modifications with the new version of the 3rd party VCL component. At some point, this can become so much work that it's easier to just maintain the 3rd party component separately. Before one knows, all time gained by the "quick fix" is lost.
The situation doesn't have to be as dire as depicted above. In cases where it is not easy to add or change some specific behavior using what's available in non private code of the component, why not communicate with the author of the component? When your wish is generally useful for the component, it can be considered to be built-in into the component by the author itself. Alternatively, it can be discussed what functionality to expose, to make virtual in a protected section of the component to ensure that the extension can be build into a descendent class. We at TMS software are always listening & ready to communicate with our component users to make our components as suitable as possible for all kinds of scenarios and to make the path to follow release cycles of our components as smooth as possible. If this involves integrating a specific desired feature, exposing something as virtual method or anything else that can make your life easier and our component better, we are ready to listen and discuss what the best way is to follow. I am sure that most other 3rd party VCL component developers do the same.
Make your life easier and communicate with the component authors, it will benefit all parties involved on long term!
This blog post has received 3 comments.
All Blog Posts | Next Post | Previous Post