DLG Outline

MORE PRODUCTIVITY MORE QUALITY MORE USABILITY

Building application software based on DLG-components is so easy that even people of a somehow computer-related business, who never thought of anything like "programming", can offer their own application software now. And since they are well-versed in the field, they can make it much more  usable  and  user-friendly  than the former "software wizards".

DLG is sold in the following packages. Each package comprises a set of components.
Click a name to read an outline of that component:
package components
DLG Basic Static + Edit, Button, ListBox, ComboBox, Tabs, DirSelect, Operations 1
DLG Standard Spin + Slider, Progress, Animation, Display, Operations 2
DLG Advanced TreeView, ListView
DLG Launching Standard Dialog, SimpleDialog, MessageLoop, MainWindow, User Arranging
DLG Accessories Statusbar, Toolbar, Menu, Floating UIF

After each section we provided a bookmark at the right edge of the screen (top). You can jump back to the top by clicking on it.

DLG Basic

In this package all the controls needed for most applications are combined. These are the controls equivalent to those of standard Windows, plus some extensions that are lacking in standard Windows, while being required even in basic dialogs. Additionally, all controls of  DLG Basic  can have callback procedures for handling single/double clicks by left/middle/right mouse button and for entire sub-classing.
If the user has a wheel mouse, all controls of  DLG Basic  can also respond to rolling the wheel (if it is provided with the respective callback procedure).
Static + Edit
With Static and Edit controls you can build elementary user dialogs, with the messages prompting the user being displayed by Static's, the user inputs taken in by Edit's.

This demonstrates the most significant features of DLG: Variables in calling program accepting the user inputs are associated right at the time of creating the controls. User inputs can be checked before closing the dialog. Controls are created dynamically, at runtime. This means, no static declarations (= at compile time) in an .rc-file are needed. All this at a quality unimaginable in standard Windows: color, brush, bitmap pattern, different fonts, multimedia support - simply by one additional DLG option.

For details look at Sample 1.0.

top

Button
Like its standard Windows equivalent, the DLG button can be modified by its  style  parameter. Additionally, in DLG there are new styles for  bistable  and  multistable  buttons. Buttons can be  flat ,  face-only   or  pushlike . By special DLG options they can have text or graphic face. New in DLG there are  Xstep  and  Ystep  buttons. Additionally, when clicked they can have a  highlight  and/or they can  alter  their text or graphic face.

In DLG, buttons can be combined to  groups  and  sub-groups . So they can emulate another functionality, seemingly unrelated to buttons (for an example see  Operations 1 ). All this in full DLG quality, plus  multi-media support.

For details look at Sample 1.1.

top

ListBox
In standard Windows, handling a ListBox requires much programming.

In DLG you need just one code line to unleash all the ListBox functionality. Thanks to a special DLG notation you can load a ListBox from an ASCII-file, from a string, from a directory structure on disk, or by your own callback procedure.

A ListBox can be  single-select  or  multi-select . Each ListBox item can have a 32bit-balue associated. Foreground and background can be embellished by color, brush, bitmap pattern, fonts and different letter sizes.

All this, of course, with variables in the calling program being associated, too. Before launching the dialog, the initially selected item(s) are fetched from the associated variable. Before closing the dialog, the item(s) selected by the user are optionally checked and then stored-back to the associated variable.

For details look at Sample 1.2.

top

ComboBox
Like ListBox, handling a ComboBox in standard Windows is quite a chore. In DLG, however, the ComboBox was designed to be more "programmer-friendly". With only one line of code you can have all the standard functionality plus associating it with a variable in the calling program, input checking and the abundance of DLG embellishing.

As well, a ComboBox can be loaded from an ASCII-file, from a string, from a directory structure on disk, or by your own callback procedure.

Similarly you can have embellishing by color, brush, bitmap pattern, fonts and different letter sizes, and an associated variable in the calling program.

For details look at Sample 1.3.

top

Tabs
The new Tab-control of standard Windows provides "tabbed" dialogs: according to the current tab, a new "folder" opens up and new controls become visible. Thus a dialog can be extended far beyond the limits of one narrow screen.

In DLG the same principle was adapted, optionally based on standard Tab-controls, sub-classed Tab control, Tab control with graphic symbols (icons or bitmaps), or Tabs emulated by a button sub-group (combined with  Operations 1 ).

Combined with  MessageLoop  a tabbed dialog can be made much more "user-friendly" than in standard Windows, with all features being accessible by mouse and keyboard as well.

For details look at Sample 1.4.

top

DirSelect
DirSelect is a DLG-specific control, with no equivalent in standard Windows. In many applications you need to prompt the user for a directory. Instead of simply having it type in, it is much more "user-friendly" to provide a graphic representation of the current directory structure on all drives in the system. When clicking a drive, it expands to its sub-directories of level 1; clicking further goes down to level 2; etc.

Eventually the full path to an elementary directory is complete. The user double-clicks the desired directory, and its path is stored back to the associated variable.

For details look at Sample 1.5.

top

Operations 1
When combining DLG controls with DLG operations, you can implement a wealth of functionality with not a single line of programming. You can fully concentrate on implementing application-specific parts by programming callback procedures. This will boost the productivity of your software development enormously.

DLG operations are implemented by an option of a button. When the user clicks it, the operation is activated.

 Operations 1  is a collection of some of the most frequently needed operations. It comprises the following operations:
  • Sub-dialog for the user choosing a file.
  • Sub-dialog with a DirSelect.
  • Presenting a help text.
  • Memorizing user inputs in a ComboBox.
  • Emulating a tabbed dialog by a button sub-group.
For details look at Sample 1.6.

top


DLG Standard

This package combines controls needed for applications that are supposed to be not only of a "basic" kind but offer some user-friendliness too, giving them a more professional touch. At the back of your mind, you can also use them to get a message across touching upon your marketing behind the application.

The controls of  DLG Standard  can have callback procedures for handling single/double clicks by left/middle/right mouse button and for entire sub-classing.

If the user has a wheel mouse, all controls of  DLG Basic  can also respond to rolling the wheel (if it is provided with the respective callback procedure).
Spin + Slider

Spin and Slider are controls for numeric user inputs via mouse and/or keyboard, for extra user-friendliness. There are similar controls among the new common controls of standard Windows but they are providing much less user convenience. Besides the usual DLG embellishing, with DLG sliders you can have a display field showing the current slider value printed in digits, in an application-specific string, or the output of your own callback procedure. By its  style  and various DLG options a Spin or a Slider can be employed very flexibly: The user can set the desired value directly or in a combination of large and small steps.

If the user has a 3-button mouse or a wheel mouse, a   Spin  or a   Slider  can also be operated on by pressing the middle mouse button or rolling the wheel. For wheel operations, you do not even need to program a callback procedure.

For details look at Sample 1.7.

top

ProgressBar

"An application can be technically perfect; but if it's not geared to the needs of the human user, it can be practically worthless!" - Typically this happens with lengthy operations.

Just imagine: The computer is working at full capacity. Yet, on screen there seems to be nothing going on. The user gets bored, then irritated, eventually presses any key (at random, perhaps) - and all that "perfect" application ends up in a crash. Maybe, some hours of work are lost. Of course, the user puts the blame on you, the software developer.

A good software designer would have foreseen this problem and would have presented on screen any visualization of what's going on internally. ProgressBar provides a vast multitude of options to give an impression of the internal activities.

For details look at Sample 1.8.

top

Animation

Animation is, similar to a ProgressBar, a DLG-specific control to illustrate the internal activities during a lengthy operation. However, a ProgressBar presumes something like a "completion" = that its duration can be calculated in advance. In practical use this is frequently not true, for a number of reasons. Still, for good software design you should present to the user any kind of "eye-catcher" on the screen.

With an Animation control you can take advantage of an application-specific series of bitmap images. Cleverly used (e.g. when combined with multimedia support) this opens up a new communication channel for your marketing!

For details look at Sample 1.9.

top

Display

In DLG you can use many colors, fonts, patterns, and graphic symbols. To present them to the user, you need any kind of control that's simply beyond the concept of standard Windows. DLG provides a way to display a color, font, etc. in its natural form (keeping away from the user that computer-internally it's just another numeric value). This is what can be done with a Display control.

A Display can be either stand-alone or combined with any of the  Operations 2 . There are implemented several sub-dialogs for the user choosing a color, a font, etc. The result is made visible in a Display.

Additionally, there is a Display-based control named "Scribble_Pad". By it you can have a 2-way communication with the user. You can use it, for example, to present any bitmap image. On this background the user can click or freehand-draw at any place. Your application gets a message with the coordinates of the point clicked or where the mouse was moved. From these coordinates it can conclude what it means in terms of internal representation (in an application-specific data structure). A Scribble_Pad can even be combined with an Animation and/or a background color/brush/pattern.
You can fully concentrate on the application-specific aspect; all drawing on screen you can leave to DLG. By only 1 line of code you can call a DLG-procedure that's implementing a functionality worth some thousand lines of code.

Typical examples would be applications of  computer games,  computer-aided instruction (CAI)  or  edutainment  applications.

For details look at Sample 1.10.

top

Operations 2

 Operations 2  is a collection of frequently needed UIF-operations of a more advanced kind. With not a single line of programming you can implement an impressive user interface. All you need to program are the application-specific parts, implemented in callback procedures.

In  Operations 2  you have the following operations:
  • Sub-dialog for choosing a color,
  • for choosing a font,
  • for choosing a bitmap pattern,
  • for choosing a graphic symbol (icon or bitmap).
  • Variable user dialogs (cover/uncover a part of the dialog box).
  • Attaching a pop-up menu to a button.
Thus you can provide a "menu bar", simply by a group of buttons.

For details look at Sample 1.11.

top


DLG Advanced

DLG Advanced  combines controls needed for applications with rather higher standards. In many of them there is a special problem: They are to be fit for masses of application items, from a few items up to many thousands of items. Still, there should be a "user-friendly" way to present them. The monitor screen should not be perceived as being over-crowded. The user should always have the feeling that it's easy to keep an overview and to select one or any number of items for further processing.

The products of  DLG Advanced  are designed to help you building such "advanced applications". Of course, all controls of  DLG Basic  can have callback procedures for handling single/double clicks by left/middle/right mouse button and for entire sub-classing.

If the user has a wheel mouse, all controls of  DLG Basic  can also respond to rolling the wheel (if it is provided with the respective callback procedure).
TreeView

In many advanced applications there is a natural tendency of application items to form a hierarchy. It suggests itself to use this fact to present masses of items, with the name of each item representing the title of the associated sub-group. Only elementary items appear in their own right. Optionally, non-elementary items may be preceded by a mark telling the user that there is still another sub-group hidden beneath them.

In addition, items may carry graphic symbols conveying intuitively their meaning of "closed book", "open book", "document", etc. (A clever software designer can, simply by using communicative symbols, bring a TreeView-application up to a higher level of "user-friendliness".)

Users can "open" super-ordinate items at their own discretion, without being limited by the size of the TreeView control. If there are too many items for being presented within this size, scroll bars appear automatically. By handling them (in any way appropriate for scroll bars) the users can scroll all over the items. An opened sub-group that is no longer relevant can be closed again, thus saving some screen space.

This user-friendliness, however, has its price: The programmer has quite some problems when using TreeViews in an application. It takes some time of "learning by mistakes", till you can program TreeViews efficiently.
This is where DLG comes in. As usual, a TreeView can be loaded from an ASCII-file, from a string, from a directory structure on disk, or by your own callback procedure. By a number of DLG options the behavior of a TreeView can be modified down to the finest details. Thus, in the normal way of application building, there is not a single line of programming.

For details look at Sample 1.12.

top

ListView

A ListView makes use of another fact to present masses of items within a limited space. Many items do have only one main property, along with a number of "sub-items" of minor importance. Items can be sorted, alphabetically by the main or any of the sub-items. By the same way as in a TreeView, items are symbolized by graphic symbols.
However, a ListView presents the items in four different ways. In Large- and Small-icon View such as in List View the items are represented only by their names and their graphic symbols. Sub-items are presented only in Report View.
Whatever the view, scroll bars appear automatically when there are more items than can be displayed at once. Thus, the user can scroll all over the items. If provided by the application, users can switch to the one view suiting their purpose best.

Again, a clever software designer can do very much for an application being perceived as being user-friendly. Simply by using highly communicative graphic symbols, and by considerate assignment of symbols to each class of items.

However, the same problem as with a TreeView holds true also here. A ListView is a very user-friendly control but extremely hard to program. ("Oh, that's how assembler programming will have been in the late 1950's, when the first Higher Programming Language came into the market!" This was a very poignant remark of a programmer who did his first steps with ListView programming in standard Windows.)

A DLG ListView can be loaded from an ASCII-file, from a string, from a directory structure on disk, or by your own callback procedure. In DLG, many options are available to modify a ListView's behavior

For details look at Sample 1.13.

top


DLG Launching

"Launching" is programmer's jargon for presenting something to the user, on the monitor's screen. Every time you want to prompt the user for some interaction, you need to "launch" a user dialog. In standard Windows this is quite a laborious matter; you have to work in two or three files alternately (usually called ".c-" or ".cpp-file", the ".rc-file" and perhaps a ".h-file"). In DLG, however, everything is done in one file, the source code.
Standard Dialog

DLG dialogs are "dynamic" dialogs. This means they are created at runtime, without any "static" declaration in a .rc-file, without any DLL, etc. With DLG dialogs you can launch quite the same kind of user dialogs as in conventional Windows programming, with a few lines of code only. An enormous productivity gain!

But DLG provides also a quality of user interface that is unparalleled so far: color, brush, pattern, font, letter size, multimedia support. Look around: even the "global players" in the software business make do with boring gray UIF's. With DLG you can make your applications clearly "outstanding" at first sight.

For details look at Sample 2.1.

top

SimpleDialog

Many user dialogs have some things in common. The dialog box exceeds the area occupied by the controls by a little margin only. They are symmetrical (left margin same as right margin, top and bottom margin are the same) They use similar window styles. Consequently, it should be possible to standardize all these parameters to  default  values. If you then find a way to let the programmer easily override these defaults - you have  SimpleDlg .

Thus you can launch exactly the same user dialogs, with much less programming: You can do without any dialog procedure; DLG uses a default dialog procedure then. In many applications you want to program only the  WM_COMMAND  messages; then you write an appropriate callback procedure and leave all the rest to DLG defaults.

Additionally you can have all the embellishing options like in full Dyn. Dialog.

For details look at Sample 2.2.

top

MessageLoop

There is something like a  MessageLoop  in standard Windows, too - but it is not accessible to the programmer. It is hidden somewhere deep in all those Windows features providing interaction with the user: accepting user input by mouse and/or keyboard, displaying outputs to the user. If you want to do your own user interaction, you need to have a specific MessageLoop. With a DLG MessageLoop you can do semi-modal dialogs (a DLG-specific programming technique providing a special user-friendliness). Thus you can make your applications more convenient to use than they could ever be with standard Windows.

For details look at Sample 2.3.

top

MainWindow

If you want to implement an application in conventional programming, it's quite an effort to only get the basic features - but it's not really an intellectual work. To save you from that boring coding troubles is one of DLG's major goals.

In a purely technical sense you could implement an application without  MainWindow  (if only in a long-winded way). With  MainWindow  however, it takes a fraction of the time. And just this is what makes DLG so different!

For details look at Sample 2.4.

top

User Arranging

In modern applications you just cannot present to the users a once-and-forever layout. You have to provide enough flexibility as to arrange a dialog's layout by the users themselves as they see fit, and still it should be looking good at any time.

Examples of such layout modifications the users have come to expect are stretching/shrinking the dialog box or moving the split bar between two (or more) dialog controls.

In conventional programming this would require an enormous effort that would render the one or the other project simply uneconomical. In DLG-based applications, however, it's just a few options more.
Extra time effort: a few seconds.

For details look at Sample 2.5.

top


DLG Accessories

Strictly technically speaking, an application could be built perfectly by all the other DLG products. However, in DLG Standard it was indicated already that an application can easily be practically worthless if it is only  technically  perfect but it is not designed for use by human beings. For this purpose, DLG comprises some features that are not absolutely necessary in technical terms, but nearly indispensable if you want your applications to be accepted as "really user-friendly".
StatusBar

A nearly universal problem in software design is that you should give the user some insight into what's going on internally - without sacrificing too much screen space. A good solution to that is, to provide a permanent 1-line area at the bottom of the screen where informative messages will be displayed. (More serious messages, such as warnings or errors, are usually displayed in a temporary message box.)

DLG goes beyond standard Windows in that a StatusBar can be used not only for display of informative messages, but it can be made to a "sub-dialog" of its own. A clever software designer can use it, for example, to accommodate some other controls there. (Typically they are a Button, a Progress, or an Animation; however, in DLG any type of control can be part of a StatusBar). This has the advantage that hardly any user will click on a Button inadvertently. It takes a certain determination to move the cursor to the StatusBar and to click purposefully there. So it would make sense to place some controls there that will be used only occasionally, say for configuration, and should never be used aimlessly.

For details look at Sample 3.1.

top

ToolBar

The problem in many multi-purpose applications is, the user needs a sub-set of all the tools built in, according to the task at hand. At the time when another task becomes relevant, another sub-set is needed. So, at first sight you may think that it would be best to have *all* tools on screen. However, too much of screen space would be occupied then by things that are not useful most of the time. Moreover, the user would constantly be forced to hunt for some tools that are placed somewhere on the other end of the screen.

With a DLG ToolBar, however, you can provide much more convenience to the user. Simply design only the most frequently needed controls fix into your screen layout. The rest of the tools you should arrange in task-specific toolbars. If the users want to have a certain sub-set of tools on screen, they can activate the appropriate toolbars - one or more, just as wished. When the users decide to do away with a toolbar, it's only one mouse click and the space occupied by it is free again.

In DLG a ToolBar can be declared "Relocatable". Then the users have not only the choice which tools are on screen at a time but also their arrangement is up them.

In standard Windows there are usually only buttons and, at maximum, a ComboBox included in a ToolBar. In DLG, however, any type of control can be there.

For details look at Sample 3.2.

top

Menu

Menu is actually an old method to offer the user a bunch of operations, with a minimum of screen space being occupied. In DLG, however, it was enriched by some details that can make it much more powerful.

For example, in a DLG menu any of the pre-programmed operations can be activated (see  Operations 1   and   Operations 2 ).

In a DLG menu an item can be associated with an informative message in the StatusBar (if there is one in the application).

In standard Windows, programming of menu handling is a very tedious job. In standard Windows there are some 30 menu-related runtime procedures, each with a special, very rigid formalism. In DLG all of them have been combined to one procedure that is much more flexible to use.

For details look at Sample 3.3.

top

Floating UIF

This is a very user-friendly way to provide a user interface, virtually unknown till now:
  • Menus and toolbars do not occupy the screen space permanently. They just pop up wherever the user clicks the right mouse button, offer only the tools requested, store the user inputs back to the calling program, and disappear when they are no longer needed. The working area on screen is free again.
  • Menu items can be painted in any background color, brush or pattern. Items can have any height and width. Their lettering can be in any color, font and letter size. The text can be left-aligned or centered. So it's easy to make the user intuitively grasp an item's meaning.
  • Tools are not arranged at fixed places. Not the cursor must be moved to the tool - the tool pops up where the cursor is. The user needs to do only minimal cursor movements. (Thus "floating".)
  • User inputs are stored back to the calling program by a user action or, optionally, automatically - the user doesn't even notice it.
  • In programming, a complete menu hierarchy (nested menus and toolbars associated to menu items) is not more than a few lines of code.
By a  Floating UIF  an application can be provided with a user interface much more comfortably to handle than conventional menus and fixed tools in standard Windows.

For details look at Sample 3.4.

top

Home | Outline | DLG