• Overview
• Starting secondary sessions
• Passing information to other sessions
• Notifying other sessions

Also, applications may be structured into multiple sessions, for example a main menu program started by the user (a main session), then secondary sessions for each application module started as separate programs from the main menu.

Each JDLG session allows for one active Dialog. Thus, multiple sessions enable the user to work with multiple active Dialogs at the same time.

Applications may use a convenient JDLG function to programmatically start secondary sessions. Also, sessions may pass information and send notifications among each other.

Note: Programmatically starting secondary sessions does not require any user interaction if main session and secondary sessions share the same eloqsd server and port, and the login credentials are cached.

The purpose of a secondary session may be, for example, to display additional information based on the main session's current Dialog. In this case, it might be convenient that the main session stays in foreground, i.e., that the secondary Dialog does not put itself into foreground when it becomes visible. This can be achieved by setting the Dialog.yield attribute to nonzero. (Note: Requires JDLG version 2.0.0 or newer.)

Note: Since JDLG version 2.0.14, the Application.start attribute may be used as an alternative. Like System.start, this starts a secondary session and, in addition, allows to pass specific information as start atoms which the new session can obtain with DLG GET Application.atom[].

For example, a session may set one or multiple atoms to store context information before it starts a secondary session.

The new session then calls DLG GET System.atom[] to obtain that context, for example to display specific information.

For example, one session's Dialog might display a specific process, while secondary Dialogs might have been opened to display related documents. Once the user closes the main dialog, the application is expected to close all related Dialogs.

JDLG supports this by allowing to define Dialog notification codes by setting the Dialog.notify[] attribute. (Note: Requires JDLG version 2.0.0 or newer.)

For example, an application's notification codes could be organized by category, type, action, like below.

Example for notification category:

• Category 100: Customers
• Category 200: Products
• Category 300: Orders

Example for notification type:

• Type 60: Data
• Type 70: Document

Example for notification action:

• Action 4: Close
• Action 5: Update

Furthermore, an application could implement responding to the rule values below:

• Rule 1000: Close the Dialog
• Rule 1088: Update the Dialog

Given this example, a customer data Dialog would be configured like:

Dialog customers {

  # Customer data Dialog, CLOSE notification (100+60+4)
  .notify[164] = 1000

  # Customer data Dialog, UPDATE notification (100+60+5)
  .notify[165] = 1088

  ...
}

A customer document Dialog would be configured like:

Dialog customer_doc {

  # Customer document Dialog, CLOSE notification (100+70+4)
  .notify[174] = 1000

  # Customer document Dialog, UPDATE notification (100+70+5)
  .notify[175] = 1088

  ...
}

A session may call DLG SET System.notify[] to notify active Dialogs in other sessions which have a specific notification code. (Note: Requires JDLG version 2.0.0 or newer.)

For example, when the user closes a customer data Dialog, the program could notify all other sessions to close the related customer document Dialogs by calling:

!
! Send CLOSE notification to related
! customer document Dialogs (100+70+4)
!
  DLG SET System.notify[174],Custno$
!

The Dialogs having notification code 174 (customer document, action: close) in other sessions, if any, now submit a rule 1000 (as defined with Dialog.notify[174] above).

Here, the notification value is Custno$. This value is available in the submitted path. For example, it could be used to only close the document Dialog if it is related, i.e., if the customer number matches.

As another example, if the user is processing a specific order in the main session, an application could allow to open the related customer record in a secondary session. When the user navigates to a different order the related customer Dialogs should follow.

To achieve this, the order Dialog could notify any Dialogs having notification code 165 (customer data, action: update) in other sessions, by calling:

!
! Send UPDATE notification to related
! customer data Dialogs (100+60+5)
!
  DLG SET System.notify[165],Custno$
!

Notes:

• The following enhancements are available since JDLG version 2.0.14:

• If an active Dialog (a topmost and visible Dialog) is not interactive (if the program currently does not wait in DLG DO), or if a POPUP BOX is open, the Dialog was not notified before JDLG version 2.0.14, i.e., the notification was lost.

  This is solved since JDLG version 2.0.14. The Dialog remembers the notification as pending and submits it the next time DLG DO is invoked.

  However, when the Dialog becomes invisible, or when the program invokes DLG DO on a different Dialog, this pending notification is reset and will not be submitted anymore.

  This way, a program can rest assured that System.notify[] only notifies those Dialogs in other sessions which are active.

• Alternatively, the System.notifyall[] attribute, available since JDLG version 2.0.14, may be used to send notifications to all Dialogs in other sessions, regardless of whether or not they are active (topmost and visible).

  If a Dialog is currently interactive (if the program currently waits in DLG DO), it is notified immediately.

  Otherwise, the notification is submitted the next time DLG DO is invoked on the Dialog. However, please note that this will happen even if the notification was sent a long time ago, and even if the Dialog has never been displayed before.