<>
Navigation between forms is used all over the application and gives the user a possibility to easily find related information. From a development perspective, there are a couple of mechanisms that provide navigation.
The Application Forms framework provides
Zoom
functionality to find referenced information. To explicitly navigate from one
form to another, the form methods SessionNavigate
and
SessionNavigateWithParams
are used. Typically a navigation is invoked
from a context
menu item on a form.
To transfer data from one form to another when navigating, you use the
framework global object Ifs.Fnd.ApplicationForms.Var.DataTransfer
.
As a developer it is possible to Create
a Standard Data Transfer or Create
a Customized Data Transfer.
To start a dialog box or a wizard dialog you use the dialogs' static
method ModalDialog
. This method shall always return either of the constants
Sys.IDOK
or Sys.IDCANCEL
depending on if the user clicks the
OK or the Cancel
button. Typically a dialog box is started by clicking on a Link Label or by
selecting a context
menu item.
Dialogs that must be dynamically opened, e.g. when not having a reference to
the component that owns the dialog in your project, should use
SessionModalDialog
.
Optionally, parameters can be passed, both IN and OUT, within the method. The
framework will try to find a corresponding static method ModalDialog,
one with matching parameter types and, if found, call it dynamically. Therefore,
all usage of SessionModalDialog
can be done first having defined a
static method ModalDialog
in the owning component.
By that, the owning component will have a well defined API making it aware of
all the "entry points" to the dialog since the only way to open the
dialog will be through one of the defined ModalDialog
methods.
Arguments can be passed within the SessionModalDialog
to (IN)
the dialog. The return value from SessionModalDialog
is the same
that is returned from the ModalDialog
method (e.g.
Sys.IDOK
or Sys.IDCANCEL
)
Scenario: The dialog dlgCreateChangeOrder, hosted in
the CHANGE component, is to be opened from the CONMGT component
having four arguments passed to it.
Since the CONMGT component do not have any references to the CHANGE
component, it can not use the strongly typed method
dlgCeateChangeOrder.ModalDialog
and should instead use
SessionModalDialog
.
public static SalNumber ModalDialog(Control owner, SalString sChangeSourceType, SalString sChangeSourceId, SalString sCompany, SalString sChangeSourceName)
{ dlgCreateChangeOrder dlg = DialogFactory.CreateInstance<dlgCreateChangeOrder>(); dlg.sChangeSourceType = sChangeSourceType; dlg.sChangeSourceId = sChangeSourceId; dlg.sCompany = sCompany; dlg.sChangeSourceName = sChangeSourceName; SalNumber ret = dlg.ShowDialog(owner); return ret; }
Example: ModalDialog implementation in component CHANGE
SessionModalDialog("dlgCreateChangeOrder", this, sChangeSourceType, sContractNo, sCompany, sContractName);
Example: Dynamic call made from component CONMGT
Arguments can be, apart from being passed to (IN) the dialog, also retrieved
from the dialog (OUT). Since the dialog is dynamically opened, there are no
strong types nor signatures exposed for the developer. Instead, each dialog
contains a property named DynamicReturnArguemnts
which purpose is
to contain the attributes that are about to be sent back to the calling
SessionModalDialog
method as out parameter of type
iDynamicReturnArguemnts
Scenario: The dialog dlgBusinessObjectBySupportKey,
hosted in the CALLC component, is to be opened from the SUPKEY
component having one argument passed to it and one argument returned from the
dialog.
Since the CALLC component do not have any references to the SUPKEY
component, it can not use the strongly typed method
dlgBusinessObjectBySupportKey.ModalDialog
and should instead use
SessionModalDialog
together with the
iDynamicReturnArguemnts
interface for returning
arguments. Inside ModalDialog
,
settings of DynamicReturnArguemnts
is done naming the out parameter as ATTR,
which will result in having the same value(s) available in the out
parameter iDynamicReturnArguemnts
public static SalNumber ModalDialog(Control owner, bool callerIsCaseHeader) { dlgBusinessObjectBySupportKey dlg = DialogFactory.CreateInstance<dlgBusinessObjectBySupportKey>(); dlg.callerIsCaseHeader = callerIsCaseHeader; SalNumber ret = dlg.ShowDialog(owner); // Set the return argument "ATTR" making it available as out parameter in dynamic SessionModalDialog calls dlg.DynamicReturnArguments.Set("ATTR", dlg.sAttr); return ret; }
Example: ModalDialog implementation in component
SUPKEY
iDynamicReturnArguments returnArgs; if (SessionModalDialog("dlgBusinessObjectBySupportKey", this, out returnArgs, true) != Sys.IDOK) return; SalString sAttr = SalString.Empty; if (!returnArgs.TryGetValue("ATTR", out sAttr)) return; // sAttr contains the "ATTR" value returned from the dialog. ...
Example: Dynamic call made from component CALLC
Note: iDynamicReturnArguments contains several overloaded methods, handling the most common data types (e.g. SalString, SalNumber, SalDateTime)
A dialog utility class is available exposing specific help methods. One in
particular, IsAvailable
, might often come in
handy when checking if a dialog is available.
private void menuItem_CreateCompany_Inquire(object sender, FndCommandInquireEventArgs e) { ((FndCommand)sender).Enabled = DialogFactory.IsAvailable("dlgCreateCompany"); }
Example: Enable/Disable the menu item depending on if the dialog is available or not
Note: Available = Installed in the system and granted to the user
Dynamically opened dialogs uses a design that has been deprecated in
Applications 9. Opening such dialogs dynamically was often done using
Sal.CompileAndEvaluate
and
return arguments were passed using the static property
Ifs.Fnd.ApplicationForms.Var.g_DlgReturnValues
.
Method / Property | Status | Replacement Method / Property |
Sal.CompileAndEvaluate |
Removed | SessionModalDialog |
Ifs.Fnd.ApplicationForms.Var.g_DlgReturnValues |
Deprecated | iDynamicReturnArguemnts |