The Visual Component Framework (VCF) was designed to make application programming in general, particularly applications with User Interfaces, much easier than it currently is with typical development tools. In addition it was created to be cross platform in design, so a program relying only on features within the VCF should simply recompile on another platform supported by the VCF.
Designing an application is a complex task, especially when User Interfaces are factored in, and typically are difficult to change, especially as more and more features are added to the project as time goes on. While some tools simplify this through a RAD (Rapid Application Development) methodology, they are usually unsuited for final use due to constraints of the language. Microsoft's Visual Basic, which allows rapid prototyping of a UI, but lacks many critical features of a framework (such as a consistent Event model across all components, or some form of a Model-View-Controller architecture), in addition it is also slow, which is a draw back for high performance applications, in other words, Adobe isn't going to drop C/C++ in favor of VB for writing any of their products. Even for corporate applications, while VB is suited for many tasks where performance is not critical, there are many cases where C++ is preferred, and is ultimately used. Thus, in my experience, it is a reasonable assumption that most real applications end up being written in either C or C++, with more and more applications being written exclusively in C++.
Not only is designing the application complex, but mastering the various common tasks the application must typically perform are also complex, such as displaying one or more windows to the user, the creation of forms for entering information, laying out the various controls in a consistent manner relative to one another, trapping various events, either generated by the OS, or in the application itself. Working with the OS, in this case MS Windows, API is often a frustrating experience, and is time consuming and error prone, and full of all sorts of gotchas which the developer(s) must learn to work around, which takes even more time away from actually designing and implementing their application, which is, after all, their actual job. As if that is not bad enough, we then have frameworks built on this, which, while perhaps making the transition from C to C++ a bit simpler, are full of buggy kludges, and add their own eccentric solutions, which causes even more time to be spent learning their work-arounds, and once again, not spending time on what the developer was originally hired to do: write applications, not write work-arounds.
One of the things that helps simplify application development, and one of the strengths of environments like a VB or Borland's Delphi, is being able to develop with components. In other words, if my application requires forms with entries made by users, and the ability to report on all these entries, why not use a component written by someone else who has done nothing but specialize in doing this. I, as a developer, then spend more time worrying about polishing my key features of my application, and can easily integrate the third part solution without having to worry about every little piece of how it works. This is demonstrated by the thousands, upon thousands, of components available for Delphi and VB, ranging from pretty dressed up label controls, to 3D charting controls, to non-visual components for connecting to a serial port or detecting the CPU information on your computer.
Obviously this is not a new idea. In fact, Microsoft believes in it so strongly they came up with COM (the Component Object Model), but despite the massive amounts of money and man power thrown behind it, it is not easy to use, is often frustrating to work with, and has a steep learning curve. So, recognizing this, they are now introducing their newest foray into the world of componentized architectures with the introduction of .NET, which, not surprisingly, has as one of it's primary designers the former lead engineer for Delphi's VCL component architecture, Anders Hjelsberg.
Therefore it would be nice if we as developers had some framework that provided a solid foundation of common services, as well as support for easily implementing an application, either entirely from code, or through the use of a visual tool that facilitated easily designing UI features, and allowed the extension of that environment through new components as time went on. In addition a framework like this would wrap the common pitfalls usually associated with the particular platform, and free the developer from having to worry about them, with more time to work on their application.
This now brings us to the VCF, which is my attempt to address all of these issues, because I got sick and tired of wasting my time fighting with existing poorly designed and poorly implemented C++ frameworks. In short, why use the VCF? Because it makes your life easier. Period.
Component Architecture. The VCF is built with an architecture that supports components. In order to do this successfully there are several features that need to be in place, one of which is a rich run time type system, or a reflection API. This is found in almost any framework like this, from Delphi's VCL, COM's type information interfaces (most notably ITypeLib, and ITypeInfo interfaces), Java's Reflection API, and .NET's System.Reflection interfaces/API. The VCF is the only C++ framework (that I am aware of) that can expose the level of detail that is required without breaking the C++ language. Other solutions to this problem involve either proprietary extensions to the language that can only be compiled using the proprietary compiler (i.e. Borland's C++ Builder), or an additional required pre-processor step necessitating a proprietary pre-processor to create the real C++ that is used (some examples are Intrinsic Graphics horrid Object Definition Language that pollutes up C++ class headers, making them largely unreadable, or TrollTech's QT C++ “extensions” that require their MetaObject Compiler before producing usable C++ code). Through the use of templates, and optional macros, a developer can determine exactly the amount of runtime information he or she wishes to expose for any class that is written. This information includes the class name and class UUID, the super class, the interfaces the class implements, the methods of the class, the properties the class has, and the events the class supports. This is vital for creating a component system that can be edited visually at design-time, since the system will not have direct knowledge of the specific component.
Uniform Event System. The VCF has a uniform event system, that allows any object to listen to events fired by any other object in the system. In addition, since more than one object can listen and respond to event(s) fired off by another object, you're not locked into a one to one correspondence like you are with WM_XXX message handlers or MFC message maps. The event system is based on the Observer pattern, and will be very familiar to developer's who have worked with Java or Delphi/C++ Builder before.
Standard Application Services. The VCF supports common application development services such as providing common dialogs (like print, file open, file save, file browse, etc), undo/redo, persistence through a variety of different stream types (memory based, file based, text based, binary based, RTTI property based, etc), easy access to a registry, error logging, threads, timers, tool tips, images, layout management, and a rich set of controls that are also easy to extend. In addition, on Win32 platforms, there will be support for COM, making it easy to embed existing ActiveX control/components in VCF based applications.
Peaceful Coexistence with existing code. The VCF can co-exist with existing frameworks/API's as well. If you already use MFC a lot, you can easily incorporate VCF object's within the context of your MFC App. Perhaps you find the graphics capabilities in the VCF preferable to those provided by MFC. No problem, just create an instance of a VCF::GraphicsContext and you're off and running. Likewise, perhaps you have a Win32 app, and you'd like to use some of the controls in the VCF, or perhaps you'd like to add multi-threading to your app and use the VCF::Thread class to make your life simpler. All of these things are very easy to do, and can be done with either static or dynamic linkage to the VCF libraries. This is in stark contrast to the MFC approach. Using practically any UI class (i.e. CWnd, CDC, CPen, etc) outside of a full blown MFC app is simply not possible – MFC is an all or nothing proposition.
Small binary re-distributable size. Developers are often concerned about the size of either the executable that is produced and/or the size of the required libraries if dynamic linking is used. Since the VCF is a framework you obviously cannot get all of the many features in it for free, but is still smaller than to MFC or QT (total size is a bit under 2 megabytes). It can, however, be compressed, with no discernable performance hits, to less than 700Kb, making it much smaller than it's competition. Since the VCF is broken up into several core libraries, you can get the basic set of classes (those encapsulated in the FoundationKit) in a DLL weighing in at around 118 Kb.