Also an Application Framework (AF) has its limits - it is not without ANY programming. Yet, most of its functionality is pre-programmed already. Only application-specific features are to be programmed by the applier. And that's a fairly straightforward programming.
Applications without ANY programming? No. - By their very nature, the components an AF is made of can cover only those parts of an application's functionality that occur all over the applications of a class. (Say, text processors, spreadsheet calculators, etc. - to name just the most prominent classes). Beyond that, however, in every application there are a number of "application-specific" features. They can be implemented only by manual programming.
All we at 1st Components Design could do was, to design our components as universally as possible. And to make the integration of the applier's own programming as easy as we could. So we have quite a number of universal components meanwhile. Some of them are equivalent to their standard Windows namesakes (e.g. "Edit", "Button", "ListBox", etc.)
Pretty soon we found some features occurring in a great part of all applications that are not provided by standard Windows, though. An obvious example is what we called "DirSelect". That's a component of which, when activated, a TreeBox pops up with a tree of all the directories and sub- directories on the user's disk. To select one of them, the user just is to select it from the graphical tree. Then the TreeBox disappears again, the application continues - but now with the full path to the sub-directory selected by the user. If you think how many applications there are asking the user for any (new, or already existing) sub-directory - you can't help wondering why this was not provided in standard Windows already!
The second thing we did was to make sure that conventional programming can be seamlessly integrated in an Application Framework made up by DLG components. All the Windows objects created by DLG components can be handled by conventional programming, just as if they had been originating from the clumsy standard Windows resource declarations. That's to say, the Windows system itself does not notice any difference between DLG and the objects created in the usual way. The differences are visible to the applier only.
Most of the DLG components have (optional) "callback procedures". In them the applier can program how certain operation steps are to be done. An example that will be needed in many applications is the "SelProc". In it the applier tells the Windows system what is to be done when the user selects an item in a ListBox, ComboBox, TreeView or ListView. In most applications this will be the place where the user interaction will be transferred to the internal processing - which, of course, is always application-specific, by the inherent meaning of the term "application".
In an Application Framework there is something that could be called "programmer interface" (in analogy to the well-known "user interface"). The programmer interface of a SelProc is very simple. Its prototype is
void SelProc (HWND hCtl, int idx)
hCtl is a window handle to the
component (ListBox, ComboBox, TreeView or ListView).
idx is an index of the selected
item(s).
By these two variables the applier has full access to every single item of the
component.
Also most of the other callback procedures have a "programmer interface" that's reduced to its simplest constituents. Thus the programming of callback procedures in general is a rather straightforward job, much easier than conventional Windows programming.