Eloquence A.05.11 is mostly a problem fixing release.
We stongly recommend to install it, if you
PRINTER SYNC
If printing to a file (or a pipe), the printer subsystem (PRINTER IS) uses a buffer to minimize the necessary system calls. The PRINTER SYNC does force a flush of this internal buffer, so all data which are currently buffered are output.
Please note, that this is not necessary and has no effect for PORTs (TIO) as they always passby the internal buffer.
This was releated to a race condition in the database cache code. It was triggered by the additional concurrency due to the presence of multiple processors. This patch is recommended for all systems with multiple processors.
This was caused by an internal inconsistency in the user interface code.
Internally all index keys are unique. This is achieved by appending a unique number to each key. The highest used unique number was incorrectly reset if another index was added to a data set. This could result in duplicate internal key values.
This was caused by a code sequence like below:
REQUEST 11
CALL X
ON INPUT #11
SUB X
ON INPUT #11 GOTO Got_it
WAIT
Got_it:
A$=AREAD$(11)
SUBEND
In this case, the subsequent ON INPUT in the main segment tried to
"re-use" the ON INPUT target from SUB X. This is of course
impossible and will now result in a runtime error 312.
The TIO interrupt target is currently a global ressource and is not saved when a subroutine is called. So if the subroutine does use ON INPUT, the information becomes invalidated on subroutine exit.
The configuration item IdmLib now overwrites previous settings. If previous settings should be preserved, IDMLIB must be included as an IdmLib path component:
UNIX: IdmLib=/myapp/dlg:$IDMLIB
DOS : IdmLib=c:\myapp\dlg;%IDMLIB%
The former behavior was to append the previous IdmLib setting
(from the default section or the IDMLIB environment variable).
Eloquence and the Dialog Manager (DM) use different character set encodings. Eloquence previously used the code page translation built into the Dialog Manager. This sometimes resulted in a wrong translation, for example when passing a string argument to a DM rule (DLG CALL RULE).
Codepage character translation now works in any context. This was accomplished by setting the DM to the ISO 8859-1 character set encoding and doing the necessary character set translation ourselves.
The dialog server on the MS Windows platform had a problem retrieving the current object focus.
The following code could fail:
DLG DO "..."
DLG GET "....focus",A$
The MS Windows specific event filter eventually disabled the
current focus object so that the object focus could not be retrieved.
In this case a special lookup is done now to retrieve the focus even
if it has been disabled.
This was caused by an internal inconsistency.
Using dialog modules resulted in a file descriptor leak on each DLG LOAD. This caused a dialog server failure after the number of available files have been spent. Since this was a problem in the Dialog Manager runtime, we were unable to fix this. Eloquence now uses the DM A.03.04a runtime.
Using dialog modules results in a file descriptor leak on each DLG LOAD. This causes a dialog server failure after the number of available files have been spent. This is a problem in the Dialog Manager runtime.
RUNSRV does not correctly synchronize with DDE server applications which have a long start-up time when running in a WIN32 environment. This occurs because the WIN16 Yield() and YieldDirected() API calls have no effect so that RUNSRV has no chance to determine when the WIN32 DDE server has completley started-up.
This should go away, once we have a native WIN32 port of the Eloquence client software.
DLGSRV has a problem on radio buttons. This occurs when a radio button looses its focus due to a client-server transaction and afterwards another radio button of the same group is activated. When control returns, the focus is restored to the previously activated radio button. The problem is: Setting the focus in DM/Windows is equivalent to activating a radio button.