In the current implementation, Eloquence WEBDLG is fully object- and
attribute-compatible with ASCII DLG. However, some attributes are not
used due to the functional differences between DLG and WEBDLG (see below).
The main differences are caused by the fact that a web browser serves as
the frontend for your programs. Another reason is that there is no
permanent connection between the user's browser and your program. This
implies the following limitations and known problems:
Most of these limitations depend on the completeness of the HTML 4.0
implementation in future browser versions.
- To convert the DLG character coordinates into a WEBDLG layout, a
configurable coordinate raster is used. However, the real font and
dialog control sizes depend on
a) the browser type
b) the browser version
c) the user's settings
and thus cannot be predicted. Therefore, the WEBDLG layout tries to
match the genuine DLG layout as close as possible but this may not
always succeed completely. If necessary, the coordinate raster can
be configured with the
- The origin of any dialog or POPUP BOX is always 0/0 regardless of the
dialog's real x/y specification. This is intended and can easily be
changed by means of user-defined
files. For example, adding <center> to the very end
of the EloqPageHeader template file and </center> to
the very beginning of the EloqPageTrailer template file causes any
dialog or POPUP BOX to be centered.
- The presentation of the various dialog controls can be defined using
Cascading Style Sheet (CSS) definitions (see below). However, these
do not have the same effects with all browser variants. In particular,
the Netscape 4.x browsers ignore some of them. This may cause for example
that the contents of a listbox are displayed with a non-proportional
font although the CSS definition tells to use a proportional Courier
font. Especially, any kind of border attributes don't seem to work
correctly with Netscape 4.x. We are trying to overcome all of these
limitations in a future release.
- WEBDLG relies on specific synchronization points in your programs.
These are currently DLG DO and POPUP BOX. This implies e.g. that a
DLG DRAW command does not have any effect on the user's browser
until to the next DLG DO.
If it is inactive your dialogs won't work.
- The .sensitive and .editable attributes are
correctly translated into HTML but not all browser variants care
about them. This can result in non-editable edittext fields to be
editable and insensitive buttons to be clickable.
- Not all browser variants allow to specify the dialog tab order or
even if insensitive controls are skipped in the tab order. This may
cause undesired effects if your programs rely on a particular tab
- Any Eloquence enhancement switch characters are not displayed. This
has always been the case with the Windows GUI (DLGSRV), too. Also, the
new Java DLG behaves the same. As a conclusion, Eloquence enhancement
switch characters are considered ASCII-DLG-only and will probably never
be supported with WEBDLG.
- Accelerator keys are correctly translated into HTML but since this is
an advanced HTML 4.0 feature there is currently no browser available
which supports them.
- The on-line help system is not implemented yet so the HelpText object
class currently is not functional. It is however implemented for
- WEBDLG supports some but not all of the new objects and attributes
introduced with Java DLG. It is however planned to make both near to
100 percent compatible if possible.
As noted above, using Cascading Style Sheet (CSS) definitions, the
presentation of the various dialog controls can be defined. Such
definitions should be inserted into the
or - if you do not define a page header - into the
The following CSS definitions are taken from the page_css_header.tmpl
CSS header example file located at
/* These style classes define the presentation of
the dialog controls */
/* statictext class */
/* edittext class */
/* read-only edittext class */
/* listbox class */
/* pushbutton class */
/* checkbox class */
/* radiobutton class */
Separate CSS classes take place for each DLG control. Note that read-only
EditText controls (which are normal EditText controls with the .editable
attribute set to 0) have their own class.
However, not every browser applies these styles the same way. In
particular, the Netscape 4.x browsers ignore some of them. This may cause for
example that the contents of a listbox are displayed with a non-proportional
font although the CSS definition tells to use a proportional Courier font.
Especially, any kind of border attributes don't seem to work correctly with
Additionally, CSS can be used to customize the appearance of POPUP BOXes as
well. The following example, if inserted into the CSS definitions contained
in your page or CSS header, would display your POPUP BOXes with an inverse
layout (white on grey/black). The box would be surrounded by a 3 pixels
3D-border (once again: don't expect this to work with Netscape 4.x):
/* POPUP BOX border and background */
/* POPUP BOX text color */
/* POPUP BOX button color */
Please note: Using CSS to set the POPUP BOX border width
requires that the PopupBorder
configuration is set to 0.
There are many different styles applicable, such as font family, size,
color etc. We cannot guide you into CSS here, but there are a lot of
resources available, either as printed books or on the internet.
- A comprehensive CSS reference (the site provides additional resources as well)
- Dave Raggett's Introduction to CSS
- Information about available browsers and their CSS implementations
- CSS tips & tricks