"Universal" components with keyword options, fine. But what if you have a great number of options? What if you want to provide some of them only tentatively? - The "Dispersed Arguments" technique is an answer to that.
In a preceding article I declared the "keyword options" to discern our universal components from the ubiquitous buzzword "components". "For a few options this might be all right", you might object now. "But what if you have a great number of options, some of which you are not sure if they are really needed and want to provide them only tentatively?"
That's right. Even if you have only a small number of options, it gets a bit clumsy if you have nothing but conventional programming. For example, let's assume you want to declare the exact dimensions of a window. In conventional programming you could do it like that:
int t = 12, l = 34, w = 56, h = 78;
"Top=%d Left=%d Width=%d Height=%d", t, l, w, h
If you have constant arguments, you could code it as well like this:
"Top=12 Left=34 Width=56 Height=78"
What would you do if you are not clear about, say, the option "Height=" ? Should it be "78" or would, for example, "87" look better? - In conventional programming you could do nothing better than providing two code lines only one of which is in effect, the other one is commented out:
"Top=12 Left=34 Width=56 Height=78"
// "Top=12 Left=34 Width=56 Height=87"
And so on - you could easily come up with many more things that would wreak havoc on your coding. In the end you would feel like an assembler-programmer who has to keep overview over many pages of code of which only a few lines are the point.
We at 1CD realized that we needed a more elegant "programmer interface" than what is provided by conventional programming. For a plain-text string of keyword arguments it was indispensable to have all the options one by one, with the argument value next to the keyword. Something like the following:
int t = 12, l = 34, w = 56, h = 78;
"Top=%d", t, "Left=%d", l, "Width=%d", w, "Height=%d", h
If your argument values are constants, you can of course write them within the ""-pairs or even all options within one ""-pair.
In case you want to provide an option tentatively, write it in a separate line. So you can easily comment out just the one option in question:
"Top=12 Left=34 Width=56"
"Height=78"
// "Height=87"
Thus the DLG-code is very similar to standard C/C++. For that comfort you have to pay only a small price: the end of an option series has to be marked by a zero:
"Top=%d", t, "Left=%d", l, ... , 0
By that syntax of DLG you can even have optional arguments within an option. A typical example is the option "Image=", as it is needed in many contexts, e.g. for declaring a bitmap series to a group of buttons. By default each image in the bitmap series is assumed to be 16 x 16 pixels. For example:
"Image=*IDB_TOOLBAR" or "Image=#Toolbar1.bmp"
depending on whether you declare a bitmap-resource in your application's .rc- file, or you want to have extracted the images from a .bmp-file.
But you can override that default easily by setting one or two additional arguments for the height and width of all images in the bitmap series. You could code it, for example:
"Image=*IDB_TOOLBAR,%d,%d",w, h
or, if szImage = "Toolbar1.bmp":
"Image=#%s,24,%d", szImage, h
When you download DLG, it comes as a package of an #include-file, a static library (Dlg.lib) and the documentation (Dlg_xx.pdf, xx ... index of the DLG- grade you downloaded). It will be automatically installed such that you can call any DLG-procedure just like any of the many runtime functions of standard Windows programming.
In the eyes of the compiler, the DLG-code is just a normal C/C++ code. For applying DLG you need nothing special, only a normal development system (like Visual C/C++). Usually a software developer will have that anyway, as it is needed for conventional programming. No further investment needed.