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:

• 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 XRaster and YRaster settings.

• 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 EloqPageHeader and EloqPageTrailer template 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.

• WEBDLG relies on JavaScript to be activated on the user's browser. 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 order.

• 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 compatibility reasons.

• 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 page header or - if you do not define a page header - into the CSS header.

The following CSS definitions are taken from the page_css_header.tmpl CSS header example file located at /opt/eloquence6/share/example/webdlg/:

   <style type="text/css">
   <!--
   /* These style classes define the presentation of 
      the dialog controls */

   /* statictext class */
   .eq_statictext
   {
   }

   /* edittext class */
   .eq_edittext
   {
     font-family:Courier;
   }

   /* read-only edittext class */
   .eq_edittext_ro
   {
     font-family:Courier;
     background-color:#ffffe0;
   }

   /* listbox class */
   .eq_listbox
   {
     font-family:Courier;
     background-color:#ffffe0;
   }

   /* pushbutton class */
   .eq_pushbutton
   {
   }

   /* checkbox class */
   .eq_checkbox
   {
   }

   /* radiobutton class */
   .eq_radiobutton
   {
   }

   //-->
   </style>

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.

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 */
   .eq_popup_box
   {
    border-color:#808080;
    border-width:3px;
    border-style:groove;
    background:#808080;
   }
   /* POPUP BOX text color */
   .eq_popup_text
   {
    color:#ffffff;
   }
   /* POPUP BOX button color */
   .eq_popup_button
   {
    color:#ffffff;
    background:#000000;
   }

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.

Links

http://www.w3.org/MarkUp/Guide/Style

Dave Raggett's Introduction to CSS

http://www.w3.org/Style/CSS/#browsers

Information about available browsers and their CSS implementations

http://www.w3.org/Style/Examples/007/

CSS tips & tricks