WHO SHOULD  NOT  BUY DLG

From experience we know that once in a while among our customers there are some people who purchased DLG in wrong expectations. The DLG-approach is a bit different from conventional programming. You should not buy DLG if you are one of the following types of person:

TECHNICAL BACKGROUND OF DLG

DLG is a series of pre-programmed software components for implementing applications under Windows 95/98/NT/2000. DLG was developed in Visual C/C++. DLG components are supplied in form of a static library and can be used in a C/C++ development system just like any of the runtime functions.
The only programming you need is that for 'callback procedures'. To that purpose you don't need full C++, you can do it in simple C. You don't even need full-time programmers.

DLG is language-independent. What the end-user sees, are graphics only. (Yes, there are some messages in standard English in DLG. However, they appear only during application building, visible to the programmer only. When an application is released, they can be switched off easily.)
The only messages visible to the end-user are those you display in a callback procedure.

A special idea in the design of DLG was to associate each user input element with a variable in the calling program. When the dialog is opened, the respective element displays the current value of the associated variable. Before the dialog is closed, all values in the user input elements are stored back to the associated variables in the calling program.

Optionally, before closing the dialog   an input value can be tested to have any user input at all, or to fit in with a given range of values. If these criteria are not met, closing the dialog is refused until the user has entered a valid input. You don't need to take any precautions for queer user inputs, what makes conventional Windows programming so troublesome.

By doing so, the programmer can fully concentrate on working on the application-specific parts. Calling a DLG dialog is as simple as, for example, a standard MessageBox. When execution returns to the calling program, the user inputs can be processed right away.

OPTIONS, KEYWORD PARAMETERS

The design of DLG started out with the idea, the applier should be able to pass any number of parameters when creating a dialog. Without being nailed down to that awkward formalism of standard Windows programming.
Our solution is the concept of "Options": a series of arguments strung together in a normal ASCII-string.

The arguments have the form of keyword parameters:  "<keyword>=%<format specifier>",<value>,   with at least one whitespace character (space, tab, line break) between two arguments. The window text is used to accommodate the options, with a special character separating options from the text that is supposed to be the real window text.

Options may occur in any order (with a few exceptions that are specifically pointed out in the documentation).
Option strings may be formed manually or by standard Windows string functions at runtime. Thus you can have a  variable dialog,  a dialog that adapts widely to previous user inputs - one more thing that is easy in DLG but very limited in conventional Windows programming!

Due to this concept an applier has very much latitude in how to implement a user interface. In addition, the most frequently needed operations are available in pre-programmed form. Special requirements can be implemented in callback procedures.

Therefore, with DLG you need no programming at all (at least as far as UIF is concerned). Most things are implemented by combining pre-programmed features. The programmers can concentrate on the aspects specific to the application.

CALLBACK PROCEDURES

DLG is a set of universal components for building "Application Frameworks" . Meaning, you can build an application by a minimum of programming. You simply combine DLG components according to the features you want to have in the target system. Additionally, in DLG you can get many effects that are just beyond standard Windows programming, e.g. colors, fonts, multimedia support, etc.

If there are some details left that you cannot get directly from DLG, you can program 'callback procedures'. They are very much straightforward programs implementing application-specific details. You don't need to care about all those subtle intricacies that are usually involved with programming (in particular that of Windows applications).

For example, a callback procedure implements the application's response when the user ...

single- or double-clicks a mouse button clicks left, middle or right mouse button rolls the wheel (if the user has a wheel mouse) selects an item from a list (by mouse or by keyboard) etc.