Blog

All Blog Posts | Next Post | Previous Post

Easing the application lifecycle with 3rd party components

Wednesday, June 2, 2010

The 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!

Bruno Fierens

This blog post has received 3 comments.

1. Wednesday, June 2, 2010 at 10:56:29 AM

That''s reminded me that I have some local changes I need to ''propose''...

However, one approach that might be very useful to developers using your components would be to make source code available via a Mercurial repository: As well as making branching/merging changes easier, it would simplify installation of new source - you would just do a "pull" form the remote repository.

Currently I place copies of your source inside a local VCS, which is some help, but not as good as being integrated with your own...

Pratt Roddy

2. Wednesday, June 2, 2010 at 5:45:09 PM

Sadly sometimes it''s not a question of "saving time" but actually getting something working in the way that it should have done in the first place.

Our job is to meet our customer''s needs, not make our component supplier''s lives easier/products better for *their* sake or for the sake of fellow developers. Our customers won''t thank us for that.

Example - we recently found a serious flaw in the handling of Unicode XML values in the VCL XML transform code.

The code hasn''t even changed significantly in Delphi 2010. My guess is that the issue was resolved as a side-effect of the change to Unicode "String" type, but that only occurred in Delphi 2009, and they aren''t likely to be fixing Delphi 2006 any time soon (and neither they nor anyone else is going to contribute toward any of the costs we will incur in updating to 2010 either!).

But in any event, the way we handle this is using a "Vendor Library Branch" in our SVN repository. As a result, merging our changes with updated vendor versions is usually relatively straightforward, and as a bonus we are also able to see exactly what has changed in each vendor update, independently of our revisions.

Jolyon Smith

3. Friday, June 4, 2010 at 9:46:09 AM

@Jolyon,

> Sadly sometimes it''''s not a question of "saving time"

Too right. I think I still have a few "patches" for VCL/RTL bugs in some products.

> ... Our customers won''''t thank us for that.

BUT, your customers *will* thank you for using the best, most reliable and most stable development tools and components - and reporting bugs/enhancements (and maybe even suggested patches) back to the vendors/developers is a small but worthwhile contribution towards this.

It''s a "community" thing, which applies IMO as much with commercial products as open source ones. If *your* customers weren''t reporting problems back to you that would be a bad sign, surely?

- Roddy