Wizard Controls
The wizard control is the primary component of the wizard. It can reside only on the wizard form type, and only one wizard control can exist on any given wizard form. Each wizard control contains multiple pages; each page is comprised of one subform or alias. Each page corresponds to a task that the user must complete to finish the wizard. During runtime, the wizard displays the first page and waits for the user to complete the task. Typically, you use the pages to prompt the user to provide input. After completing the task, the user clicks the Next button, and the wizard validates page one data and displays the second page in the list (index). In a standard scenario, the user continues in this fashion until the last page is reached, at which point the user clicks Finish and the wizard re-validates and commits the data before terminating.
You can opt to display the progress list itself (which also enables the user to jump between tasks by clicking a task in the progress list), and you can also display a progress indicator which shows how much of the wizard is complete without listing the individual tasks. The progress list indicates which pages have been completed, which ones have errors, and which ones have warnings by displaying icons next to affected tasks. You cannot alter these icons programmatically. Additionally, the control automatically provides certain buttons on each page of the wizard. It provides a Previous button on all but the first page, a Next button on all but the last page, a Finish button on the last page, and an Exit button on all pages. You can add additional buttons such as Save and Cancel, but you cannot remove these default buttons.
You can enable users to start a wizard and then save it to finish later. If a user saves, the control does not automate saving the data for you. Instead, you must react to the WIZARD:Save for Re-entry event and save the data programmatically. If you enable revisits on the wizard, the interface provides a Save For Later button as well.
The subforms included in the wizard have no form- or control-based limitations; that is, you can employ the full range of subform features and system functions. Therefore, to create an effective wizard application, you must be proficient with subforms.
Each subform is parented to the wizard form which means that subforms cannot communicate with each other directly; they must share data using the wizard form. Data can be passed in one of three ways: from page to wizard form (child to parent), from wizard form to page (parent to child), or in both directions. Only data in the child page data structure can be passed to the parent wizard form. Consequently, you must plan the data structures carefully. In general, objects in the data structure will fall into one of two categories: items which the page will want to share with other pages, and items which the page will require such as input from other pages or the wizard form itself.
You can embed subforms and use an alias to a reusable subform. You can programmatically reorder the pages (therefore reordering the tasks). You can also indicate a starting page other than the first one in the list. As the user progresses through the wizard, tasks that the user has completed are referred to as upstream tasks. Those which the user has yet to complete are referred to as downstream tasks.
You are not limited to forms inside the wizard. You can use form interconnections to link to forms outside of the wizard. If you use an interconnection, the forms that appear are called satellite pages. Like the wizard itself, satellite pages expand to fill the entire frame; the standard JD Edwards EnterpriseOne navigation menu is hidden. When the user clicks OK on the satellite page, the wizard reappears displaying the page containing the object that triggered the interconnection.
Forms have different statuses including indeterminate (no state), complete, and incomplete (but continue). No state is the initial, pristine state of a page and it indicates that the page has been initialized but not yet visited. Complete indicates that the page has been visited, finished successfully, and validated. Incomplete indicates that the page has been visited but not yet finished or validated. All pages in the wizard must be at a status of complete before runtime can commit data.
Runtime validates all wizard pages when the user clicks Finish, even hidden and disabled pages. To prevent a page from being validated and saved, enable the Form Design Aid (FDA) property, Suppress Validation and Save. During runtime, use the system function, Suppress Wizard Page Validation and Save. As a rule of thumb, call the Suppress Wizard Page Validation and Save system function for all hidden and disabled pages in the wizard to prevent Finish button processing on them.
When a wizard application is launched, runtime sets the status of all pages to no state as part of the initialization process. When the user enters a page of indeterminate status, runtime changes its status to incomplete to reflect the fact that the user has visited the page. These are the only times that runtime sets the page status. Application logic is expected to manage page status otherwise. However, runtime will not permit the application to assign a complete status to a page until all its errors have been resolved.
All pages must be at a status of complete for the Finish button process to succeed, even hidden and disabled pages, unless validation is suppressed for those pages. If any page is not set to complete, the Finish button process will fail and no data will be saved. To set page status, use the Set Wizard Page Status system function.