Issue 31790  —   3GL executed in the context of the wrong instance

Status:   Planned for resolution in 10.4.01

Solution available in patch(es):      10.3.02.027    9.7.05.040

Description:

 Summary:
 When executing a Uniface 3GL function from Proc then (in certain scenarios) it
 can happen that it is executed in the context of another instance (instead in
 the context of the instance from where the 3GL is called).

 Environment:
 +Uniface:
 * Version 9.7

 +Operating System:
 * OS independent

 +Database:
 * DBMS independent

 Symptoms:
 A Uniface 3GL function (e.g. for data manipulation or Proc-Like functions)
 should be executed in the context of the instance from where it is called. In
 certain scenarios it, however, can happen that the 3GL function is executed in
 the context of another instance.

 Consider the following scenario:

 1. From a start-up shell the non-modal form FRM1 is activated
 2. In the Execute trigger of FRM1 the non-modal form FRM2 is activated
 3. FRM2 retrieves some data into a Grid from the Execute trigger
 4. From the Read trigger a Uniface 3GL function is called (e.g. UFGET to read
 data from a field of the Grid entity)
 5. Next form FRM2 is shown by an edit statement
 6. After retrieving (e.g.) the first 10 hits (default step size of hitlist)
 FRM1 is becoming active again
 7. In FRM1 an edit is executed and the form becomes visible
 8. Now FRM2 will continue to read data until the visible space of the Grid is
 filled with occurrences

 => The first occurrences read after FRM2 becomes active again is executed in
 the context of FRM1 (and not, as expected, FRM2); as a result, UFGET will not
 return the expected result, since the addressed field does not exist in FRM1

 => When checking (e.g.) $instancename from 3GL (using e.g. USYSPARM with the
 code 7004) or the Proc tracing (by using e.g.
 $proc_tracing_addition=[I=%%$instancename]) then the instance of FRM1 is
 returned and not the one of FRM2

 => For subsequent occurrences the called 3GL functions are executed again in
 the context of the correct instance (i.e. FRM2)

Workaround:

 Placing the call of the Unfiace 3GL functions in (e.g.) a collection operation
 and then calling the operation first should resolve the problem.

Notes: