Massachusetts Institute of Technology Web Dynpro for ABAP Volume I: Foundation By: Hendrik Pieterse 27 January 2011
Massachusetts Institute of Technology
Web Dynpro for ABAP
Volume I: Foundation
By: Hendrik Pieterse
27 January 2011
27 January 2011 2
Agenda
Purpose
Key Features
Development Environment
Architecture
UI (User Interface) Layout
Framework Event Loop
Controller Hook Methods
Assistance Classes
Application Programming Interfaces
27 January 2011 3
Purpose
Forms SAP Standard for ABAP Web Applications
Integrated Runtime and Graphical Development Environment
Provides Application Developers the following key advantages:
Declarative and graphical tools to the reduce implementation effort
A structured design process
Strict separation between the layout and business data
Reuse and better maintainability by using components
Easy to change layout and navigation using Web Dynpro tools
Automatic data transport through data binding
Automatic input checks
User interface accessibility is supported
Prerequisites: Requires knowledge and experience with Object-Orientation (i.e. ABAP-OO)
The following are the key feature of Web Dynpro for ABAP:
Extensive sets of User Interface (UI) elements
Support for end-user Drag and Drop (between certain UI elements)
Customizable styling
Floating popup windows
Document Upload/Download UI elements
Timed Events
Adobe Flash integration
Adobe Form integration
Web Dynpro Code Generation Wizard
Modification-free enhancements to SAP Standard code
Key features
Development environment
System Architecture is based upon the Model View Controller paradigm with:
Clear separation between business logic and display logic
Uniform meta model for all types of user interfaces
Execution on a number of client platforms
Extensive platform independence of interfaces
Architecture
Model (M)
Encapsulates the business rules and data
Function Models, Classes, Tables, WDA Components, etc.
View (V)
Visual presentation using the UI elements
Present data and obtain user input
Performs rudimentary input validation
Controller (C)
Serves as the “glue” between the Model and the View
Implements business logic, context-relevant input validation
Controls navigation
Architecture: MVC
Components implement and enforce the MVC pattern and
Consist of:
1 Component Controller
1 Interface Controller
1 Interface View
0 or more Windows
0 or more Views
Windows and Views have their own private Controllers
Architecture: Components
A Web Dynpro component is a reusable entity, and its creation is mandatory. It summarizes all components that are required as part of a programming unit for an executable Web Dynpro application
The lifetime of the component:
Starts when first called at runtime
(as required)
Ends with the encapsulating
application
May be programmatically controlled
during its lifetime
Architecture: Component lifetime
Web Dynpro windows, views and controllers are linked to the existence of the component itself
Component A can embed Component B in a View or Window
This method uses the Interface View
Architecture: Component re-use
Cross-Component communication provides the mechanism for efficient code re-use and encapsulated object design. Web Dynpro components can be referenced or directly embedded within Views
Alternatively, Component A can invoke a method exposed by Component B
This method uses the Interface Controller
Architecture: Component re-use
Different instances of Controllers and Contexts exist within a Web Dynpro
application
At least two object references are automatically defined as attributes for a
controller:
wd_context
wd_this
Architecture: Controllers
Controllers are the active parts of a Web Dynpro application and determine how the user can interact with the Web Dynpro application
Each controller contains program areas in which you can insert your own source
code in the following areas:
Event Handlers: Executed when a view is initialized, ended, or entered, when a user
interface element of a view triggers an action, or when other controllers trigger a
registered event
Methods: Custom functionality which can be called by other controllers
Supply Functions: Executed when necessary to initialize node elements in the context
Architecture: Controllers
Each view has exactly one View Controller, which processes the actions performed by the
user in the view
A view also has exactly one view context, which
contains the data required for the view
A view controller and the corresponding context
exist at least as long as the view is visible in the
browser. If the view is replaced by a successive
view, the local data are also no longer available.
However, the lifetime can also be connected to
the lifetime of the surrounding component
Architecture: Controllers
Architecture: Controllers
In addition to view controllers, which only control the behavior of an individual view, global controllers are defined that offer more general services for all the views of a component
Architecture: Controllers
Global Controllers: Each Web Dynpro component contains at least one global controller that is visible
within the component for all other controllers, called the COMPONENT Controller
Additional global controllers can be added in the form of Custom controllers
Each Web Dynpro window defines a further global controller
Interface Controllers: Each Web Dynpro component contains exactly one interface controller
This controller is a global controller that is visible also outside the component. It is thus part of the interface of a Web Dynpro component
Communication from one controller to the next is achieved by calling methods from a different controller
Architecture: Events
The Component Controller can define one or more events, while one or more Views implement an event handler to listen to and react to those events
Cross-component communication can be implemented using events on the Interface Controller
Note: Events created in the component controller are visible only within the Component
UI Elements Some UI elements, for example a Button have special events that are linked with user
Actions. Actions are defined within the View’s controller
Events are used to communicate between controllers and enable one controller to trigger event handlers in a different controller
Data for a component or view is stored in the special container called the Context
The Context forms a hierarchical structure - each Context has a root node, underneath which additional Nodes and Data Fields (attributes) are defined in a tree structure
All elementary data types are available for the definition of attributes. This is also used for creating the value help and error messages if invalid entries are made
A Node can be defined as a simple structure, or a repeating structure (table) by controlling its Cardinality
Architecture: Contexts
Architecture: Contexts
Cardinality Meaning
1:1 The node contains only one element instance, which is instantiated automatically
0:1 The node contains only one element instance, which must not be instantiated
1:n The node can contain multiple element instances (i.e. a table), of which at least one row must always be instantiated (and is instantiated automatically)
0:n The node can contain multiple element instances (i.e. a table), of which no rows have to be instantiated
Hint: Think of the context as a complex structure which you can define and expand interactively (without the need for SE11)
In this example, node EMPLOYEE forms a table due to the cardinality being specified as 0..n
Each row in the table has attributes PERNR, PERSG, PERSK, etc.
Context nodes can specify a SUPPLY Function, which is only involved when the Node is referenced
Architecture: Contexts
Example:
PERNR PERSG PERSK ENAME TEL NR
00000007 01 01 Mr. James Bond 555-235-0007
00000037 12 10 Ms. Money Penny 555-230-1000
Tip: When ever possible, utilize Supply Functions to update Nodes when required (Just-In-Time)
Framework generated type definitions Are automatically defined for each Controller to facilitate programmatic
access to the context
View definitions using the Controller Interface inspector
Constant for node names (not attributes)
Architecture: Contexts
constants: wdctx_context type string value `CONTEXT`. constants: wdctx_employee type string value `EMPLOYEE`.
Framework generated type definitions
There are two data types for each Node: a Simple (non-repeating) Structure, and a Table
Consistent naming convention: Context node names always start with wdctx_<node name> Structures always start with Element_<node name> Tables are always plural: Elements_<node name>
Architecture: Contexts
types: Element_employee type PERSON, Elements_employee type standard table of Element_employee with default key.
Conventions: An instance of a Node (structure or element in the table) is referred to as an
Element Lead Selection: Each Context Node has an implicit reference to the active Element, called
the Lead Selection
The automatic initialization of the Lead Selection always designates the first element of a Node
The UI can change the Lead Selection (e.g. user selects a specific row in a table)
If a Node is nested within another, each Node contains its own Lead Selection
Architecture: Contexts
Data Binding: UI elements embedded in a View can be bound to the
nodes and attributes in the context For example. The Table UI element allows for the
presentation of (and interaction with) of a context node. Context Mapping: Since each View contains its own Context (as does
the Window and Component Controller), a useful feature is provided to allow mapping Context Node(s) from one Controller to another
Context Mapping seamlessly ensures that the same data is available to all mapped Nodes
Architecture: Contexts
Example: By defining the EMPLOYEE Node in the
Component Controller, we can map it to each View which requires the data. This way the data is retained even if the view disappears
The context of another Component can also be mapped when referencing external components
Architecture: Contexts
Hint: Think of a context mapping as a reference to the
structure or table. Any changes to the values are immediately reflected to all users of the Node
The layout consists of different UI Elements, which
can be nested –their positioning is controlled by
layout variants, e.g.:
Grid, Row, Matrix (recommended), Flow
UI Elements have their own attributes which can be
specified directly, or bound to the view’s Context.
Examples include:
Enabled, Visible, Read Only, Text, Image Source etc.
Architecture: Views
A view describes the layout and behavior a user interface and contains its own Controller and Context
The view controller can contain methods for data retrieval, processing
user input and navigation
Each view has a configurable lifetime:
When Visible (recommended for infrequently used views)
Framework controlled (default)
Architecture: Views
Navigation between different views is facilitated by plugs which are part of the controller of a view and always assigned to exactly one view
Plugs are be divided into inbound and outbound plugs
Inbound plugs define the possible starting points of a view, and has an associated event handler in the view controller
Outbound plugs can be used to call a subsequent view
To navigate from one view to another, each outbound plug from the first view must be
linked with an inbound plug of the second view with the help of a navigation link
Architecture: Views
View Navigation A View can only be displayed by the browser if it has been embedded in a
window
One view is specified as the start view and is displayed the first time the window is called
Exactly one navigation link can originate from an outbound plug
Architecture: Windows
Windows define the aggregation and navigation between Views from one or more Components.
Window Plugs The window itself can define one or more inbound or outbound plugs
Using these plugs, a window can be included into a navigation chain (similar to the concept of the plug for a view)
Especially useful when embedding windows from external components into a Navigation Flow
Architecture: Windows
A Web Dynpro application is an independent program unit which connects a URL that with a window in the Web Dynpro component.
The application and URL is automatically generated by an entry in the ICM.
You can find the URL of your application in the Web Dynpro Explorer on the Properties tab
The URL of a Web Dynpro application has the following structure:
Architecture: Applications
<schema>://<host>.<domain>.<extension>:<port>/sap/bc/webdynpro/<namespace>/<application name>
e.g. http://dev_ecc_01.mit.edu:1080/sap/bc/webdynpro/sap/myFirstApp/
UI Elements: Support general user interaction and screen display
Enable the quick and simple design of user-friendly interfaces, regardless of the platform and the front end
Each interface element is based on an ABAP class Most constants are defined in class CL_WD_UIELEMENT
Allows use of translatable text: Provide $OTR:<OTR Alias> as field value Use OTR lookup using field valuehelp
Form Wizard Ability to create rudimentary form for all/specified fields in a Context Node
UI Element Reference: http://help.sap.com/erp2005_ehp_04/helpdata/EN/cd/422b035f01914e80251a660e39ab14/frameset.htm
UI Layout
Containers:
Mechanism to group related fields
Controls visual spacing using Layouts
Allows for controlling groups of controls
Enable/Disable
Show/Hide
Improves view maintainability when using descriptive names
UI Layout
Hint: 1. You can also use the vGutter element property for lists of fields (or forms) or to ver8cally
space elements without the use of containers.
2. When using certain container Layout pa@erns (e.g. Grid Layout) the Invisible element can be used to force blank spaces at specific loca8ons
Tables:
Column Grouping
Sorting
Filtering
Tree hierarchies (Master column)
Pop-ins
Toolbars
Cell Variants
Binds to Context Node + Inherits behavior from the Node
e.g. Ability to select multiple table rows -> Node Selection property
Wizard to assist with creating columns (Node attributes)
UI Layout
Useful Table attributes:
Useful TableColumn Attributes:
UI layout
displayEmptyRows Disable to collapse table if no values are found
readOnly Useful to dynamically control all Cell Editors (input fields)
visibleRowCount
Use -1 to show all rows at once
rowSelectable Deprecated - Do not use! (see selectionMode)
selectionMode
Use none to prevent row selection When using auto be aware of Node’s selection property
cellDesign Control background color for column
filterValue Bind to Context attribute to allow Filtering
groupingValue Bind to Context attribute to group rows
selectedVariant
Allows using different Cell Editors for each Row
Framework Event Loop
The following methods are invoked for each Controller by the Web Dynpro framework. By default these methods are empty
Controller hook methods
Invoked For: COMPONENT CONTROLLER
• WDDOAPPLICATIONSTATECHANGE – Processed whenever the application is transferred from
running to suspend mode and when it is subsequently restarted via the resume plug
– This method thus replaces the WDDOEXIT – Useful for:
• Releasing locks / resources
• WDDOBEFORENAVIGATION – Used to perform an additional validation contexts that
are required in the application but have not been validated in the request/response cycle yet
– This is important for more complex Web Dynpro applications in particular
– Navigation can be interrupted at this point if an error occurred during the event handling in the previous step
• WDDOPOSTPROCESSING – Called in the last process step before rendering – Allows application-specific clean-up processes
Invoked For: ALL Controllers • WDDOINIT
– Called automatically when a controller is initialized for the first time
– Useful for: • Creating instances of help classes
Initializing controller attributes • Triggering authorization checks • Setting initial values of the controller
context • Instantiation of used components
• WDDOEXIT – Called by the runtime when exiting the
controller – Useful for:
• Releasing locks / resources
Controller hook methods
Invoked For: View Controllers • WDDOBEFOREACTION
– Perform custom validations before an action is triggered
– Used for all visible views of the component assigned to the current phase model instance
– These include all embedded components
• WDDOAFTERACTION – Called for all visible views after any custom action
event handling has been processed – Carried out equally for all associated event
handlers – Used to prevent unnecessary duplicate logic in the
event handlers
• WDDOMODIFYVIEW – Called for all visible views of the component
associated to this phase model instance and the embedded components
– Used to dynamically modify the UI layout of a view, for example, by dynamically adding new view elements
Invoked For: Window Controllers
• WDDOONOPEN – Only processed when a window is opened as a
dialog box – Since the opening of a dialog box does not involve
any navigation, no inbound plug is called and therefore no event handler method is processed
– Used for initializations
• WDDOONCLOSE – Only processed when a window is closed as a dialog
box. – Used for cleanup processes
For each Web Dynpro component, you can define a uniquely assigned assistance class
Assistance classes are regular classes, but must inherit from the abstract class CL_WD_COMPONENT_ASSISTANCE
Available to each controller of the component through the pre-defined attribute wd_assist
The assistance class is automatically instantiated when a component is invoked.
Assistance classes
Benefits: Method calls of the assistance class provide better performance than calls of methods of
a Web Dynpro controller
Management of dynamic texts, via inherited method GET_TEXT( )
Texts that are combined at runtime only and/or contain variables can be stored in the text pool of the assistance class as text symbols
Uses: Create re-usable coding which is required within one or more components but not directly
linked with the layout or function of a controller
For example, a call of the application layer or UI-based editing of the data
Creation of specialized local types to be used in the Assistance Class and/or Component
Assistance classes
Generate frequently used code snippets
Implements standard SAP naming standards and code patterns
Features: Reading/Updating Context variables Invoking methods in used Controllers Initiating view navigation Generating popup windows Generating user messages
Benefits: Standardized naming conventions for
variables Standard patterns for context updates Significantly reduces manual coding efforts
API’s: the Code Wizard
API’s: Manipulating the context
Framework data types:
• Node: if_wd_context_node • Element: if_wd_context_element
Pre-defined Controller attributes • wd_context references the root Node.
Provides access to the entire context by using parent/child relationships
• wd_this references the current Controller Provides access to methods, attributes, types, constants
Read/Update single context attribute
wd_context->get_attribute ( EXPORTING name IMPORTING value ).
wd_context->set_attribute ( EXPORTING name value ).
Read/Update complete Node structure
Read/Update complete Nodes as a table
API’s: Manipulating the context
Tip: Whenever possible, read and update the complete Node structure or table for best performance
wd_context->get_static_attributes( IMPORTING static_attributes ). wd_context->bind_structure( EXPORTING new_item
index ).
wd_context->get_static_attributes_table( IMPORTING table ). wd_context->bind_table( EXPORTING new_items ).
Obtain Child Node
Obtain Lead Selection Element
API’s: Manipulating the context
DATA: lo_node TYPE REF TO if_wd_context_node. lo_node = wd_context->get_child_node(
EXPORTING name = wd_this->wdctx_<node> ).
“Alternative (Path notation)
lo_node = wd_context->get_node_path( EXPORTING path = ‘PARENT.CHILD’ ).
DATA: lo_element TYPE REF TO if_wd_context_element. lo_element = lo_node->get_element( EXPORTING index ).
lo_element = lo_node->get_lead_selection( ).
Obtain selected table rows (e.g. UI Table with multi-selection)
Release / Reload Node contents
API’s: Manipulating the context
lo_node->invalidate( ).
DATA: lt_element_set TYPE wdr_context_element_set. FIELD-SYMBOLS: <fs_element> TYPE REF TO if_wd_context_element.
lt_element_set = lo_node->get_selected_elements( abap_true ).
LOOP AT lt_element_set ASSIGNING <fs_element>.
<fs_element>->get_static_attributes(
IMPORTING static_attributes ).
ENDLOOP.
API’s: Supply methods
Supply methods are invoked ‘Just-in-Time’ and provides a tremendous performance improvement in both memory consumption and processing time compared to directly populating all nodes during controller initialization
Especially beneficial for Nested Nodes, since the subordinate node is only retrieved when the parent element (table row) is accessed
Some scenarios may benefit from an initial population of the context: For example smaller data sets with read-only data or when it is very expensive to retrieve the data
Defined by providing a method name in the Supply Function field during the Context Node definition and implementing the newly established controller method
The parent Context Element is provided for context-specific data retrieval
Example of Auto-Generated Supply Method:
API’s: Supply methods
method SUPPLY_EMPLOYEES . * General Notes
* =============
* A common scenario for a supply method is to acquire key information
* from the parameter <parent_element> and then to invoke a data
* provider. A free navigation thru the context, especially to nodes on
* the same or deeper hierarchical level is strongly discouraged,
* because such a strategy may easily lead to irresolvable situations!!
* if necessary, get static attributes of parent element
* DATA ls_parent_attributes TYPE wd_this->element_context.
* parent_element->get_static_attributes(
* IMPORTING
* static_attributes = ls_parent_attributes ).
. . .
API’s: Supply methods
. . .
DATA lt_employee TYPE wd_this->Elements_employee.
DATA ls_employee LIKE LINE OF lt_employee.
* @TODO compute values
* bind all the elements
node->bind_table(
new_items = lt_employee
set_initial_elements = abap_true ).
endmethod.
Example of Auto-Generated Supply Method (continued):
Real-world Example:
API’s: Supply methods
method SUPPLY_EMPLOYEES . DATA:
lt_employees TYPE wd_this->elements_employee,
ls_employee TYPE wd_this->element_employee,
ls_parent_attributes TYPE wd_this->element_context.
if parent_element is bound.
parent_element->get_static_attributes(
IMPORTING
static_attributes = ls_parent_attributes ).
endif.
CALL METHOD wd_assist->get_managed_employees
EXPORTING
user_id = sy-uname
begda = ls_parent_attributes-start_date
IMPORTING
et_employees = lt_employees.
CALL METHOD node->bind_table
EXPORTING
new_items = lt_employees
set_initial_elements = abap_true.
endmethod.
Real-world Example:
API’s: supply methods
method SUPPLY_EMPLOYEES . DATA:
lt_employees TYPE wd_this->elements_employee,
ls_employee TYPE wd_this->element_employee,
ls_parent_attributes TYPE wd_this->element_context.
if parent_element is bound.
parent_element->get_static_attributes(
IMPORTING
static_attributes = ls_parent_attributes ).
endif.
CALL METHOD wd_assist->get_managed_employees
EXPORTING
user_id = sy-uname
begda = ls_parent_attributes-start_date
IMPORTING
et_employees = lt_employees.
CALL METHOD node->bind_table
EXPORTING
new_items = lt_employees
set_initial_elements = abap_true.
endmethod.
Convention: Changed table variable to be plural
Convention: Changed type definition for structure (was LIKE lt_employees)
Safety measure to prevent accidental short dump
Retrieve data via Assistance Class or Function Module
Update Context replacing any existing content.
Activities 1. Establish Inbound and Outbound plugs at the View
level 2. Establish Navigation links in the Window 3. Create navigation requests in View Controller
Navigation Request •Syntax: wd_this->fire_<plug_name>_plg( ). E.g. wd_this->fire_to_details_plg( ).
Sending parameters with an Event 1. Select the Outbound Plug 2. Define the required parameters
Receiving Event parameters Manually create the parameters on
the Inbound Plug’s event handler as defined on the Outbound plug
API’s: Navigation
Message API provides consistent method to present messages to users
MessageBox UI Element consolidates all messages into single location Smart messages (linked to Context Element + Attribute) allows user to click the message
and jump to erroneous UI field with the message displayed below the field
Variety of methods depending on type of message to be presented
Possible to specify:
Message duration (permanent message vs. auto-removed once shown)
Target controller (ensure message is shown in appropriate view)
API’s: Messages
Example: DATA lo_api_controller TYPE REF TO if_wd_controller. DATA lo_message_manager TYPE REF TO if_wd_message_manager. * Obtain the Message Manager lo_api_controller ?= wd_this->wd_get_api( ). CALL METHOD lo_api_controller->get_message_manager RECEIVING message_manager = lo_message_manager. * Report a success message CALL METHOD lo_message_manager->report_success EXPORTING message_text = ’Detail View loaded successfully'.
API’s: Messages
Method Description REPORT_MESSAGE Reports a message
REPORT_SUCCESS Reports a Success Message
REPORT_WARNING Reports a Warning
REPORT_ERROR_MESSAGE Reports a Web Dynpro Message with Optional Parameters
REPORT_FATAL_ERROR_MESSAGE Reports a Fatal WD Exception Message with Optional Parameters
REPORT_T100_MESSAGE Reports a Message Using a T100 Entry
REPORT_EXCEPTION Reports a Web Dynpro Exception (May Return)
REPORT_ATTRIBUTE_MESSAGE Reports a message for this context attribute
REPORT_ELEMENT_ERROR_MESSAGE Reports a Web Dynpro exception related to context attributes
Simple success message:
Error message linked to a specific Attribute
API’s: Messages
Each controller contains a local interface that can be accessed in that controller (attribute wd_this)
Depending on the controller, wd_this can be one of the following types: − IF_COMPONENTCONTROLLER − IF_<MY_CUSTOM_CONTROLLER> − IF_<MY_VIEW> − IF_<MY_WINDOW>
Web Dynpro provides a generic Runtime API for each controller type. Method wd_this->WD_GET_API( ) returns a reference variable of type:
− IF_WD_VIEW_CONTROLLER (for all view controllers), − IF_WD_COMPONENT(for all component controllers), or − IF_WD_CONTROLLER (for all interface controllers or custom controllers).
Attribute WD_COMP_CONTROLLER is predefined for all View Controllers Provides access to Component Controller
SAP Help reference: http://help.sap.com/erp2005_ehp_04/helpdata/EN/43/9f029ae1062883e10000000a422035/frameset.htm
API’s: Controller methods
API’s: useful interfaces
Method Description GET_MESSAGE_MANAGER
Returns a reference to Message Manager in order to raise MessageBox messages
GET_COMPONENT Returns a reference to the controller’s component
GET_CONTEXT Returns a reference to the controller’s context (same as wd_context)
GET_MESSAGE Returns the Message text for the specified key
GET_ACTION Returns a reference to an Action for this controller
GET_CONTROLLER_INFO
Returns a reference to this controller’s metadata (type IF_WD_RR_CONTROLLER)
IF_WD_CONTROLLER (all interface controllers or custom controllers)
IF_WD_COMPONENT (component controllers)
API’s: user interface
Method Description GET_WINDOW_MANAGER Returns a reference to Window Manager in order to create Popup
Windows (IF_WD_WINDOW_MANAGER)
GET_PORTAL_MANAGER Returns a reference to the Portal Manager for Portal integration/navigation (IF_WD_PORTAL_INTEGRATION)
CANCEL_NAVIGATION Prevent any navigation within the application (e.g. after failed validations)
GET_APPLICATION Returns a reference to the application object (IF_WD_APPLICATION)
GET_/HAS_/CREATE_CMP_USAGE_GROUP
Returns / Creates a reference to the requested Component Usage Group
GET_COMPONENT_INFO Returns a reference to this component’s metadata (type IF_WD_RR_COMPONENT)
Hint: IF_WD_RR indicates a Runtime Repository which allows read access to a Web Dynpro application’s metadata. It consists of a series of interfaces, and allows dynamic creation of metadata, for example:
Creating Navigation links Changing View Lifespan etc.
API’s: useful interfaces
Method Description OPEN / CLOSE Asynchronously Opens/Closes a popup window
SET_ON_CLOSE_ACTION Registers a View Action to be executed when the Window is cancelled/closed
SUBSCRIBE_TO_BUTTON_EVENT Registers a View Action to be executed when the specified button is selected
SET_BUTTON_KIND Specifies which of the pre-defined button combinations should be displayed, e.g.
- OK - Yes + No - OK + Cancel - Yes + No + Cancel - None
SET_MESSAGE_TYPE Specifies which predefined icon to present in the window, e.g. - WARNING - ERROR - INFORMATION - QUESTION - None
SET_REMOVE_ON_CLOSE Indicates if the Window should be destroyed after being closed
IF_WD_WINDOW