day1 foundation

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


 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



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


 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


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


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)


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>


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


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


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


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


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


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


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:


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 ).

. . .


. . .

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:


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

day1 foundation

Documents