By DLG you can build an Application framework, by options you can override the DLG-defaults to get a more sophisticated layout and behavior of the user- interface. Still, there is some programming needed to implement the application- specific features.
The first step is "plugging together" an Application Framework. Then comes fine-tuning it by declaring DLG-options. The third step comprises three parts:
1. Consider which application-specific features need to be isolated in callback procedures.
DLG-components are designed in a way to cover the features common to a number of applications. Obviously, that doesn't mean "ALL applications". By their very nature, any component is useful only for applications of a certain "class".
This means, features particular to the individual application are NOT covered by DLG, deliberately. (If this would have been the goal with DLG, there would have to be a multitude of components, each one not very powerful. In other words: this would be the drawback for which "components" became an inflationary- used buzzword.)
Contrary to the usual "components", DLG was designed right from the start to
cooperate with conventional programming at any level.
You can use only the basic DLG-components and program nearly everything
manually. (This will be not very economical. But by DLG you are not forced to
"jump head-on" into the new software technology.)
Or you can use the top DLG-components and program only a few callbacks. (This
will be a highly economical way of software development. But it will necessitate
you to be fairly knowledgeable in DLG and to keep an overview over quite a
number of callbacks.)
Moreover, the compiler sees no difference between conventionally programmed C/C++ code and the DLG-code. To it, DLG-components are just like a call of any of the some 500 runtime functions of conventional Windows programming.
The difference of DLG-code and conventional C/C++ is visible to the human only. DLG-code complies fully with standard C/C++ syntax. It just makes use of some niches that are rarely used in conventional programming.
2. Provide the callback-options and the respective prototypes.
Next you have to do is figuring out which options are needed to link a callback procedure into the Application Framework constructed by DLG. Declare this option, thus handing over a "function pointer" to the respective callback procedure. (A "function pointer" is nothing more but the entry address of that procedure.)
Then you should look up the formal prototype of that procedure and code it somewhere in your application BEFORE it is used in a callback-option.
A typical example that will be needed in many applications is the handling of the user interaction when clicking an item in any of the list-components (ListBox, ComboBox, etc.):
void SelProc1 (HWND hCtl, int iItem, char* szItem)
{
// conventional programming goes here
}CreateCtl ( ... "SelProc=%p", SelProc1, ... );
hCtl is the window handle of the list- component.
iItem is the index of the item that was clicked by the user.
szItem is the exact wording of the clicked item.
That's all you need to access the clicked item in the list-component by conventional programming. With some extra coding effort you can even access all the other items, re-shuffle them any way you like, or whatever.
3. Program the callback-procedures in conventional C/C++
Once you have done the preceding steps, it's easy to program the application's response to the user interaction. To give you a simple example, if you want to delete the item clicked by the user from a ListBox - that's just one code line:
SendMessage (hCtl, LB_DELETESTRING, iIndex, 0);
In this simple example the item's wording is not even needed.
Programming callback procedures in general is rather straightforward programming - not very satisfactory to a qualified programmer but good for an "industrial" style of software development.
To use a historic analogy: When assembly chain work was introduced in the automobile factories in early 20. century, the automobile workers did not regard it with favor. Understandably: many of them were highly skilled specialists for whom working on the chain was really no challenge. Yet - that's what triggered the turn to a society of general affluence.