HP Eloquence A.05.02 Release Notes

HP Eloquence Dialog Server

• Installation
• Fixed problems
• Enhancements
• New functionality implemented with A.05.02
• Unsupported (experimental) RUNSRV functionality
• Dialog Manager programming notes

To print the release notes on your laser printer enter the commands below

  
   cd /opt/eloquence/newconfig/ReleaseNotes
   zcat A.05.00.lj.Z | lp -dlj -oraw

The following changes are necessary in the installation process:

• The HP Eloquence client applications for the Windows platform are now located at /opt/eloquence/share/dist/PCCLIENT.EXE. PCCLIENT.EXE is a self extracting archive.

  To transfer it to a PC you may use ftp:

  • Startup ftp on the PC system and open a connection to your HP9000 system.
  • cd /opt/eloquence/share/dist
  • bin
  • get pcclient.exe
  Please remember to use binary transmission.

• The MS Windows Dialog Server does no longer support the wsockets transport. A WINSOCK 1.1 compliant protocol stack is required.

• The following files on the Windows platform are no longer used and should be deleted if they exist. They are located in the directory C:\ELOQ by default.
  • eqsrvws.dll HP Eloquence WINSOCK 1.1 transport
  • eqclntws.dll HP Eloquence WINSOCK 1.1 transport
  • eqsrvso.dll HP Eloquence WSOCKETS transport
  • eqclntso.dll HP Eloquence WSOCKETS transport

• Due to an overflow of an internal Dialog Manager queue, it was possible, that the content of (multiline) EditText or ListBox objects and (shadowed) Record elements were not displayed correctly.

• Bad Client State: If a MS Windows Dialog Server was terminated, the .async mode was not reset. This could result in internal protocol failures.

• DLG GET ".driver" could return in a random result.

• The performance of the Windows Dialog Server has been improved about ten times. While five client/server transactions per second was a typical execution rate in recent servers, we were able to improve the transaction rate well above fifty transactions per second (without using the .async mode).

• Improved event filter

  The Windows Dialog Server event filter has been improved. During a client/server transaction, the access to objects of active dialogs is disabled. Window control elements (like title bar, window frame, minimize and maximize controls) are still accessible.

  Activating another Windows application or minimizing the dialog window could trigger the 'deselect' rule for EditText objects. This is now taken care of by the new event filter.

• New "do" attribute for window objects

  A new window attribute "do" has been provided to make it possible to keep a dialog active while a client/server transaction is in progress.

  This makes it possible to have a Cancel dialog, which may be used to notify the server program of a cancel request by the user during a time consuming server action (for example printing a report). An example program, which shows a possible use is provided in the example directory (/opt/eloquence/share/examples). In order to try this with the Windows Dialog Server, the file cancel.idm must be transferred into the dlg directory of the client (typically C:\DLG).

  Please note, that this does not work with the current Motif Dialog Server yet.

• Multiple Windows Dialog Server configurations

  Additional arguments, passed with the DLG SET ".driver" statement are no longer ignored but passed to the Windows Dialog Server. The Windows Dialog Server will use an additional argument as a section name in the ELOQ.INI configuration file. Configuration items in this sections are used to replace the default configuration as defined in the [dlgsrv] section. So only modified parameters must be specified.

  For example:

       DLG SET ".driver","@hostname Section"
  

  This will cause the DLGSRV to lookup in the section [Section] for additional configuration items.

  If the configuration item "Arguments" is present in the named section, its value will be appended to the DLGSRV commandline.

  For example, the ELOQ.INI has the following content:

       [RunSrv]
       DlgSrv=C:\ELOQ\DLGSRV.EXE -connect %s -IDMfont 1 -IDMcolor 1
  
       [debug]
       Arguments=-IDMtracefile C:\TMP\TRACE.TXT
       Debug=3
  

  Given this configuration, the statement

       DLG SET ".driver","@hostname debug"
  

  will startup the Dialog Server on host 'hostname' in debug mode 3. The Dialog Server will create a tracefile as specified by the additional commandline argument.

  The following DLGSRV configuration items may be modified by specifying an additional configuration section:

  • LogFile
  • Debug
  • DefaultsFile
  • DlgPath
  • Dlg, Idm, Idc

RUNSRV is used by HP Eloquence to startup the Dialog Server on the Windows platform. It may also used by HP Eloquence programs by calling the RunSrv.DLL. The HP Eloquence A.05.02 RUNSRV.EXE includes DDE support which may be used to control Windows applications.

• Prerequisites

  All Windows application programs you intend to communicate with using DDE must be currently running. If an application is not currently running, it must be started in order to initiate a DDE connection. Configuration entries in the [modules] section of the ELOQ.INI configuration file are used to translate from the application module name into the actual execution path.

  Add a new entry to section [Modules] for each application program you would like to start on a DDE request if it is not currently running.

  For example:

       [Modules]
       Winword=C:\WINWORD\WINWORD.EXE
  

  This makes the program 'MS Word for Windows' accessible for DDE communication, even if is not currently running. 'Winword' is the internal application module name of the application program, which may be obtained from the application documentation or the Windows task manager (the MS Windows Task List shows the application module names of all currently running programs). You need to know the application module name in order to initiate a DDE communication.

• Performing a DDE communication

  DDE communication is performed by calling the function 'RunSrv' in the RunSrv DLL.

  The call format is CALL DLL Run("RunSrv",Host$,Cmd$,Errn,Msg$).

  You have to specify your DDE command in Cmd$, the format is:

       Cmd$ = "DDE ModuleName Topic TransactionType Item Value"
  

  where:

  DDE

  is the literal string "DDE" used to identify this command as a DDE communication.

  ModuleName

  is the MS Windows application module name such as 'Winword' or 'Netscape'.

  Topic

  is an application defined communication entity you have to know from the application's DDE documentation.

  TransactionType

  defines the type of the DDE communication. This depends on application requirements for the given topic. The following TransactionTypes are implemented:

  • REQUEST
  • POKE
  • EXECUTE

  The REQUEST transaction is the only one that returns data. The only data type recognized is CF_TEXT.

  Item

  is the communication item name. This depends on the application and the given topic.

  Value

  is only required for the POKE transaction type and specifies the data to be transmitted. Do not specify 'Value' for the other transaction types.

  All these components are separated by white space and must not have any white space separators inside.

  On success, the 'RunSrv' function sets Errn to 0. After a REQUEST transaction, Msg$ contains the DDE data as provided by the application program. All other transaction types set Msg$ = "".

  On failure, Errn is set to -1 for DDE protocol errors (i.e. if the desired communication could not be established, or the given Topic name is wrong) or 1 if a DDE protocol timeout occured (i.e. a REQUEST transaction failed to receive the return data because the application program did not respond). A literal desription of the error code is returned in Msg$.

The following example will startup Netscape and will cause it to load a specific document:

    INTEGER Errn
    DIM Msg$[256]
    
    Cmd$ = "DDE Netscape WWW_OpenURL Request "
    Cmd$=Cmd$&CHR$(34)&"http://www.marxmeier.com/public/eloquence.html"&CHR$(34)
    Cmd$=Cmd$&",,0xFFFFFFFF,0"
    
    CALL DLL Run("RunSrv",Host$,Cmd$,Errn,Msg$)

• The 'Dialogbox' attribute

  If you set the attribute 'Dialogbox' for a window (Section 'Specific', Attribute 'Dialogbox': Yes) (or true) it will be treated as application modal. Any windows which are stacked below may no longer be activated. This is the default for HP Eloquence as defined by DEFAULTS.EQ and is compatible with HP Eloquence DLG.

  If you need a menu bar for a window, you must set the Dialogbox attribute to 'No' (or false), because a modal window cannot have a menu bar. (This may work for specific Dialog Manager releases depending on the settings of other attributes, but it is not portable). In this case, the window is considered modeless, windows stacked below may be activated.
  However, the Dialog Server will ignore any event from a window which has not been activated by a DLG DO statement unless the Function attribute (Section 'Standard', Attribute 'Function') has been cleared (set to null) for all objects which should trigger a server transaction.

• Using entry rules ('select') with EditText objects

  If you define a 'select' rule for an EditText object, this rule will be executed each time, when the EditText object will get the focus. When this rule will trigger a server transaction, this will result in an endless loop, which is probably not what you expected. So 'select' rules should never trigger a server transaction and should only trigger local execution.