O4W WYSIWYG
Create/Modify
From the O4W Start Menu cunder O4W WYSIWYG Form, choose Create / Modify to launch the O4W WYSIWYG Designer and Menu.
From the O4W WYSISYG Menu choose File, New to launch the Quick Form Definition.
Below is the Quck From Definition screen. The Form types are:
Form layout only – the WYSIWYG will be used to lay out the controls, but the mechanics of using the form (key lookup, reading, writing, etc.) will be controlled by a user-defined stored procedure.
OI Form Mode – A single screen solution whereby a record is read when the key field(s) are populated and focus is lost. This also provides an OI-style QBF menu.
Key and Search – A three-screen solution. An initial screen with a prompt for the key field(s) and any search criteria, an optionally-displayed screen that displays all the matching records if more than one is found, and a details screen that allows for the entry, display, and/or editing of record-specific information.
Enter key directly – A two-screen solution. An initial screen with a prompt for the key field(s), and a details screen that allows for the entry, display, and/or editing of record-specific information.
Search only – A three-screen solution, identical to the Key and Search but without the option to enter the key field(s) on the initial screen.
Picklist – A two-screen solution. An initial screen displaying all the records (possibly limited by selection criteria defined in the form layout) and a details screen that allows for the entry, display, and/or editing of record-specific information. Note that this is usually appropriate for tables containing, or limited to, small numbers of records.
Add records only – a single screen solution that allows for the creation of new records, but does not provide any mechanism for retrieving existing records from the table.
After selectiong your primary table you can choose the Fields to include on your form.
Below is the QuckForm details page on the Search Fields tab.
Select any field(s) that you wish to display on the search screen, by changing the field type from Not Used to any of the available options. You can also click and “drag” the fields to re-order them – doing so at this point will allow the QuickForm wizard to draw them in the desired order.
On the search screen, the field can either be displayed as a textbox or a listbox. Additional details for the listbox (such as the source of the list) must be specified after the form is generated.
Below is the QuckForm details page on the Results Fields tab.
Select any field(s) that you wish to display on the results screen, by changing the field type from Not Used to Text. Note that the Results screen will only be displayed if there is more than record that matches the search criteria; the results will be displayed as a table, and the first field displayed will be a link to the Form screen. You can also click and “drag” the fields to re-order them – doing so at this point will allow the QuickForm wizard to draw them in the desired order.
Below is the QuckForm details page on the Form Fields tab.
Select any field(s) that you wish to display on the detailed form screen, by changing the field type from Not Used to one of the supported types. You can also click and “drag” the fields to re-order them – doing so at this point will allow the QuickForm wizard to draw them in the desired order, and will allow multivalued associated fields to be grouped together.
The field type can be textbox; listbox, checkbox, or radio buttons (which will require you to specify the source for the values when the form is created); plain text; date picker; time picker; or toggle (which is functionally the same as a radio button).
You may also choose to organize the detailed form page into multiple tabs. If you choose to use tabs, then click and “drag” the fields for each tab so that they are grouped together, and then set the first field in the tab to “Next Tab”. This tells the QuickForm wizard to generate a new tab at this point. You can also put fields in the “General” area; this is displayed above the tab sections.
If you don’t wish to organize the detailed form page into tabs, click the “Don’t use tabs” checkbox.
You can control the default layout by indicating that you want the labels to be placed next to the fields they are associated with; or that you want the labels to be placed above the fields; or that you want the labels to be put into the fields themselves (the labels are then minimized when the field has focus).
The WYSIWYG will use the updated jQuery UI controls for checkboxes, radio buttons, and other elements; these look similar to the mobile controls. If you wish to disable this enhanced UI, click “Use ‘classic’ user interface on desktop” to display these as traditional elements.
Below is the Overall Form output displayed by the QuickForm wizard after the form has been generated. This is the key and search page, page 1.
The bottom of the display shows the page number, the name of the form (if defined), and links to the other page(s), the current page properties, and the overall form properties.
You may also access the same information from the main menu in the upper left hand of the screen – these options allow you to go to specific pages, and edit the various overall properties. Below is the Menu Toolbar and we will explore the Overall Form Properties.
Below is the Overall Form Properties page. Here you can provide a form description, and modify the form title.
On the Appearance tab, you can choose the templates to use when the form is drawn in either desktop or mobile mode, which jQuery mobile “theme” you wish to use when in mobile mode, and some default color specifications.
If you wish a menu to be displayed on this form when it’s run, choose the menu name from the dropdown here.
The height of each “cell” in the form is defined in the WYSIWYG configuration file, but can be overridden here.
You can also alter some of the values you specified in the QuickForm wizard – label behavior and new or ‘classic’ UI display.
If there are additional stylesheets or javascript files you wish the WYSIWYG generator to load, these should be indicated here.
Below is the Overall Form Properties page on the Behavior tab.
If you wish to restrict access to this form to only O4W logged-in users, change the form permissions from “None” to one of the other defined values. Only users with permissions “greater than” the permission specified here will be allowed to access this form.
If this form is a ‘system’ form, and shouldn’t appear on the list of available forms in the WYSIWYG editor by default, click the “Yes” button here.
You can override the default behavior of the form, and force all controls to be read-only, by selecting “Yes” from the dropdown here.
If you wish to write custom O4W basic+ code to interact with the form, you must create a commuter module. If you check the “Yes” box here, when the form is saved, the commuter module will be created if it’s not already on file.
If the form has been named, checking the “Yes, create commuter module” checkbox will fill this textbox in with a default suggested name; if the form hasn’t been named yet, you can specify a name of your choosing, or wait until the form is saved and named.
If “Yes, create commuter module” has been checked, you can select which form-level events should call the commuter module. You should only check the events you wish to interact with. You can add or change the events that call the commuter module at any time.
The QuickForm Wizard will generate the page(s) appropriate to your desired type of form, and give them default names. You can change the names, add additional pages, or even change the page types – each page type has its own “handler” that provides the specific behavior for that type of page.
Below is the Overall Form Properties page on the Data tab.
When creating the form in the QuickForm wizard, the default table was specified. If you created the form without the form wizard, or you wish to change the table that all the fields reference, you may modify it here.
The WYSIWYG form designer is intended to support “linkages” between multiple tables, allowing for the simultaneous editing, display, and updating of multiple tables. Note that this functionalty is not complete in the initial release.
Below is the Enter Key or Search Properties page.
In a Key or Search screen, you must specify the field(s) that are part of the key, and how you wish the search fields to be handled, along with which button(s) on the form provide which function(s).
For all fields, please indicate whether it is the key field, part of the key field (and which part), or whether it’s part of the search criteria (and how it should be used in generating the search results).
If this is a non-key field, you can specify that a null value means “do not include in the search” rather than “search for a null value”. If you wish to exclude this field’s value if it’s not specified, choose “Yes” in the “Skip in Search If Null” listbox.
The WYSIWYG form runner can perform the search with the values exactly as entered; or convert the values to upper case, convert the values to lower case, or perform a case-insensitive search.
If multiple fields are used in the search criteria, they can be joined by either an explicit AND or explicit OR. By default, they will use implicit joins.
Values to include in the search can be entered by the user (this is the default behavior), or generated by a stored procedure, or you may enter a literal value. If the value is generated by a stored procedure or is a literal value, the user will not be prompted for this field’s value. This is useful to “automatically include” certain selection criteria (to limit the records available based on a user’s permission level, for example).
If the value is to be generated by a stored procedure, or is a literal value, enter the stored procedure name or the value in this textbox.
You can select which field gets the focus when the form is initially drawn.
The QuickForm wizard will automatically create buttons that perform standard behaviors for the type of page. On the Key or Search page, for example, that includes a button to read the record if a key is entered; a button to start searching; and a button to create a new record. You can change, remove, or add buttons to the page, in which case you might need to modify which buttons are used for which action. You can select the proper button for each action here.
If you allow an “add new record” button, you must specify how the new record key should be generated. If the new record key is generated by a counter value or a stored procedure value, you will be prompted for the location of the counter or the name of the stored procedure.
On the WYSIWYG display, you can click on any of the already created fields and you will see its properities displayed in the right-hand panel. You can click on the “open folder” icon to expand the properties dialog. Below is the Text Properties page, Required tab, for a plain text field. The text that should be displayed can be entered here; use “^” to indicate the value from the data field, if this is a data-bound control. You can indicate that the form should draw the text with a line break before, after, or both before and after the text.
Below is the Text Properties page, Data tab. The QuickForm wizard will fill in the table and data field information if this field was selected during form generation; otherwise, if a table has been specified in the overall form properties, you can choose the table and appropriate data field. If the field is multivalued, the WYSIWYG form designer will attempt to determine that from the dictionary information, but this can be manually overridden here. The default value and output conversion can also be specified.
Below is the Text Properties page, Optional tab. You can choose to make a text field into a link; if you select “Yes” to the “Link?” question, you should also specify the type of link, the link URL, and the link “target”. The link URL can include “^” to indicate “the current field’s value”. The link target can be left blank, which will open the link URL in the current page, or some other explicit name to open the link URL in a new browser tab or page.
Below is the Text Properties page, Formatting tab. The name of the font to use when drawing this text can be defined, as well as the foreground and background colors, whether the text should be displayed with bold and/or italic font, the font size, and the alignment of the text (left, center, or right).
Below is the Text Properties page, Mobile tab. Since there are no specific mobile properties, the below message is displayed.
Below is the Text Properties page, Events tab. If no events are allowed – because “Use Commuter Module” wasn’t selected in the overall form properties, or because this type of element doesn’t support any events – you will see the message below.
Below is the Text Properties page, Advanced tab. This allows advanced users to specify explicit HTML before and after the element, and additional class and style names (and values).
Below is the Listbox Properties page, Required tab. Here you can define the label and its location (relative to the data value), the name to use for the data value, and the source of the list used by the listbox. The source can be one of the standard code records provided with O4W, a stored procedure, a code table, or a code record inside a table.
Below is the Listbox Properties page, Data tab. Note that you can only choose the table name from the default table, or any additional tables specified in the overall form properties. Here you can select the field from the table, and mark the field as read-only or multivalued. You can also specify a default value, and the input and output conversions and input validation (if any). You can also add “None of the above” as an option to the user’s choices for listboxes, checkboxes, and radio button sets.
Below is the Listbox Properties page, Optional tab.
You can specify a non-null height to turn your listbox into a “listbox area” of <n> lines; this is usually done in conjunction with marking the listbox as “multi select”. You can also override the default width of 20 characters.
During design mode, the values for listboxes are not normally displayed, only a description of the listbox. If you wish the values to be displayed even in design mode, you can select “Yes” for “Display values in Design Mode”.
If these values and codes are unchanging (as they normally are), you can mark “Yes” to “Static values” to improve performance when the WYSIWYG form runner is run.
Normally the codes assigned to each value are hidden; you can have the codes displayed along with the values by selecting “Yes” to “Show codes with values”.
This field can optionally be marked as a required field.
Below is the Listbox Properties page, Formatting tab. You can provide a specific font name, choose the background and foreground color(s), indicate that you wish the value displayed in bold and/or italic, and specify the justification of the value and the overall control (if the value is smaller than the overall control area).
Below is the Listbox Properties page, Mobile tab. When the WYSIWYG form is rendered as mobile output, these additional properties will be used to create an icon, specify a theme, and indicate the types of buttons that should be displayed.
Below is the Listbox Properties page, Events tab. If no events are allowed – because “Use Commuter Module” wasn’t selected in the overall form properties, or because this type of element doesn’t support any events – you will see the message below.
If a commuter module has been defined, you will see the following screen instead. You can choose to have the commuter module invoked just before entering the field; when the value has changed; and/or when exiting the field.
Below is the Listbox Properties page, Advanced tab. This allows advanced users to specify explicit HTML before and after the element, and additional class and style names (and values).
Using the menu, below, or the links at the bottom of the WYSIWYG designer, you can choose to move to the other pages of the form. For example, we can move to the “Results” screen (PAGE_2) to examine its fields and properties.
Below is a page which contains a Table. The “Results” screen displays a list of records from which the user can select a single record to examine.
Clicking on the table shows us the properties in the right-hand column; using the “open folder” icon presents the properties in the center of the screen. Below is the Table Properties page, Required tab. Here you can choose to provide a comment or description of the field, as well as specify the column header(s) for the table, table behavior (should the rows be allowed to be rearranged? Should insert and delete, or add and delete, buttons be specified?), and table display (zebra stripe?) options. You can also specify whether you want a paginated table, or a scrolling table. If you select a paginated table, you can identify where the pagination controls should be placed; if you select a scrolling table, you can specify the size (in pixels) of the scrolling area.
Below is the Table Properties page, Data tab. A table control can be either multirecord or multivalued. You can also programmatically override the record list for this section if the data to control the display should be coming from somewhere else.
Below is the Table Properties page, Optional tab. The table is normally displayed with columns of fields and rows of records; if desired, the table can be turned “sideways” so that each column is a record and each row is a field. If you wish to suppress column headers, you may choose “Yes” to “Suppress column headers”.
By default, the contents inside table cell elements ignore any specific column and row layouts; if however you have a complex table that displays complicated contents and you need to preserve the specific layout, you can choose “No” to “Suppress layout inside cells.”
If the table is too big for its parent element, you can choose to scroll the table, or grow the parent, or “truncate” the table.
Below is the Table Properties page, Formatting tab. For each column header and each column’s data, you can choose the foreground and background color, the name of the font, and the alignment; you can also specify default values for these properties for the overall table.
Below is the Table Properties page, Mobile tab. When the WYSIWYG draws the form on a mobile device, the table is normally drawn in a “responsive” style (which means that the layout will change depending on the size of the screen). You can choose to disable this behavior.
Below is the Table Properties page, Events tab. As there are no events associated with the table element, the following message is displayed.
Below is the Table Properties page, Advanced tab. As there are no advanced properties available for this element, the below message is displayed.
We can also examine, and modify, the overall properties for the current page. Below is the Edit Page (Page 2), Key List Properties page. You can specify a select statement to limit the selected records; a number above which the user will be warned about the number of rows selected; a number above which the results will be truncated; and whether or not the elements can be clicked on to be sorted.
We can use the main menu, or the links at the bottom of the WYSIWYG form designer, to change to the third page. Below is the Edit Page (Page 3), Main Form page.
If we select the page properties from the main menu, or from the links at the bottom of the WYSIWYG form designer, we will be shown the Display record contents page. Here we can specify what field should get the initial focus, and which button(s) will trigger which event(s). Although the QuickForm Wizard will automatically create save, delete, and cancel buttons, you can choose to edit, create, or remove them; here you can assign the proper button(s) to the proper action(s). You will also specify the behavior of the form wizard after a save or delete, and whether there should be an acknowledgement message after the save or delete.
Below is the full screen of the record content page, page 3. The QuickForm Wizard has drawn this “detail” page with two tabs and information in the non-tab “general” area.
Below is the Tabs Properties page, Required tab. Here you can specify the name(s) of each tab.
Below is the Tabs Properties page, Data tab. As the tabs are not data driven, there are no data properties available.
Below is the Tabs Properties page, Optional tab. If the tabs are too big for their parent elements, the overflow can be “clipped”, or the tab can be scrolled, or the tab element can “grow” to accommodate the content.
Below is the Tabs Properties page, Formatting tab. There are no formatting properties applicable to the tab element.
Below is the Tabs Properties page, Mobile tab. There are no special mobile properties applicable to the tab element.
Below is the Tabs Properties page, Events tab. If no commuter module has been defined for this form, then the following message will be displayed.
If a commuter module has been defined, and “Use commuter module” has been selected in the overall form properties, you can choose to have the commuter module invoked when the tab is clicked.
Below is the Tabs Properties page, Advanced tab. This allows advanced users to specify explicit HTML before and after the element, and additional class and style names (and values).
You can use the main menu to select one or more controls to display or modify. Below is the Menu Toolbar and we will explore the Select Control(s) option.
Below is the Select Entity/Entities page. You can use this to select one or more controls to perform “bulk operations”. You can change all the properties shown on all the selected controls at one time. You can also use this page to change control alignment, and copy or cut multiple entities at once.
To add additional elements to your form after the QuickForm wizard has finished, or when drawing a form without using the QuickForm wizard, you will click and “drag” elements from the Form Elements Toolbar (left hand panel). Once an element is dropped on the form, you will be asked to fill in the properties for that element.
The Form Elements Toolbar is divided into groups by function; click on the group that contains the element you want, and if closed, the group will expand.
The Content Layout group contains elements that contain and organize other elements. These include a section, a collapsible section (which opens and closes to show or hide its contents), a tab control, a table control, and a non-visible control block (which allows its contents to repeat based on the data that defines it).
The Groups group contains elements that are collections of similar “children” elements. These include a radio group, a checkbox group, and a button group. For the radio and checkbox groups, you can define the children elements in the overall group element (for example, you can select one of the O4W supplied control records, such as US states or world countries), as well as manually dropping in individual radio or checkbox elements.
The form elements group contains standard input and display elements. The available elements include a header/footer, a single radio button, a single checkbox, a textbox, a multiline text area, a file upload box, plain text, an image, a slider, a listbox, and a button.
The Lists group contains the elements that compose a list in the browser. These include an overall “unordered” list control (which uses bullets to mark each list item), an overall “ordered” list control (which uses numbers to mark each list item), and the individual list item itself. To use, one would draw the overall list element (either ordered or unordered), and then drag and drop individual list elements into the overall list element. Inside each individual list element, other elements (such as plain text, or images) would be dropped.
The Desktop Widgets group contains “enhanced” elements that currently are only available when run in desktop (rather than mobile) mode. These include a date picker, a time picker, a color picker, and an autocomplete list. If a WYSIWYG form includes these elements and is then run in mobile mode, the elements will be replaced with their non-enhanced standard elements (textboxes or listboxes).
The Mobile Widgets group contains “enhanced” elements that currently are tailored for the mobile device, though they can be used in desktop mode on most browsers. These include a mobile header, mobile navigation bar, and mobile footer; a grid control; a toggle switch; and a list divider.
The Graphical Widgets group contains complex elements that you can use to enhance your WYSIWYG form. These include a Google map, Google map elements (such as markers) that can be placed in the google map element, a Google chart, Google chart data that can be placed in a google chart element, and an embedded web page. Note that for use of the Google “widgets”, you may be required to obtain a Google maps API key (this is also needed for some charts, such as geochart). Instructions on obtaining a key can be found here:
https://developers.google.com/maps/documentation/javascript/get-api-key
To save your form, use the File/Save or File/Save As… options on the main menu. If you haven’t previously specified a name for the form, you will be prompted to enter one at this time.
When saving the Form you will be prompted to create the Commuter Module if it is not found on file. If it does exist, you will be prompted if you wish to overwrite the existing stored procedure, or if you wish to download the commuter module and any of its changes into a Windows editor (such as notepad) for manual integration of any changes.
When the WYSIWYG form designer creates the commuter module, it populates it with a “skeleton” to handle all the events you selected. Below is the default Stored Procedure Commuter Module created for this form.
O4W WYSIWYG Commuter Module
FUNCTION O4WCM2_PRODUCT_ENTRY(CtlEntId, Event, Request) * Auto-generated by O4W_DESIGN_FORM at 14:09:07 27 FEB 2018 * Standard equates $Insert O4WEquates $Insert O4W_Design_Form_Equates $Insert O4W_COMMUTER_COMMON rtnValue = 1 Begin Case Case event _eqc 'CREATE' * called when initially creating the form * variable 'ctlentid' is a unique identifier for this instance of the form * To abort form processing at this point, set rtnValue to 0 (rtnValue=0) and optionally set statMsg@ to desired error text and redirectTo@ to desired new page Case event _eqc 'READY' * called when form initially drawn * variable 'ctlentid' is a unique identifier for this instance of the form Case event _eqc 'PRE_READ' * called before reading record from table * variable 'ctlentid' is ID of record (if available) * examine variable bIsNew@ to determine if this is being called for displaying the search result (bIsNew@=''), * or - when retrieving the record for actual display/editing - if this is a new record (bIsNew@=1), or a record that is supposed to exist (bIsNew@=0) * set variable 'rtnValue' to 0 (rtnValue=0)to disable further event processing * set variable 'rtnValue' to -1 (rtnValue=-1) to skip READ but continue processing * (If performing the read in this code, and you intend to set the rtnValue=-1, you should: * - fill the @RECORD variable with the desired record contents * ) * set variable 'statMsg@' to desired error/status text Case event _eqc 'READ_CHECK' * called before write or delete to verify record has not been changed by another user * set variable 'rtnValue' to -1 (rtnValue=-1) to skip READ but continue processing * (If performing the read in this code, and you intend to set the rtnValue=-1, you should fill the @RECORD variable with the desired record contents) Case event _eqc 'POST_READ' * called after reading record from table * variable 'ctlentid' is ID of record (if available) Case event _eqc 'PRE_WRITE' * called before writing record to table * variable 'ctlentid' is ID of record (if available) * variable '@record' is the record contents (if available) * if any fields failed input convertion, variable 'statMsg@' contains details about the failure * set variable 'rtnValue' to 0 (rtnValue=0) to disable further event processing * set variable 'rtnValue' to -1 (rtnValue=-1) to skip WRITE but continue processing * set variable 'statMsg@' to desired error/status text Case event _eqc 'POST_WRITE' * called after writing record to table * variable 'ctlentid' is ID of record (if available) * variable '@record' is the record contents (if available) * set variable 'statMsg@' to any desired 'success' message * set variable 'redirectTo@' to url to transfer to after success Case event _eqc 'PRE_DELETE' * called before deleting record from table * variable 'ctlentid' is ID of record (if available) * variable '@record' is the record contents (if available) * if any fields failed input convertion, variable 'statMsg@' contains details about the failure * set variable 'rtnValue' to 0 (rtnValue=0) to disable further event processing * set variable 'rtnValue' to -1 (rtnValue=-1) to skip DELETE but continue processing * set variable 'statMsg@' to desired error/status text Case event _eqc 'POST_DELETE' * called after deleting record from table * variable 'ctlentid' is ID of record (if available) * variable '@record' is the record contents (if available) * set variable 'statMsg@' to any desired 'success' message * set variable 'redirectTo@' to url to transfer to after success Case event _eqc 'SELECT' * called when building list of records to display in picklist or as result of search * variable 'ctlentid' is name of list record (in SYSLISTS table) to be generated * set variable 'rtnValue' to 0 (rtnValue=0) to skip selection * set variable 'rtnValue' to -1 (rtnValue=-1) if generating list of matching ids in the commuter module * (if generating list of matching ids in this code, and you intend to set rtnValue=-1, you should create a list record with the id passed in CtlEntId) Case event _eqc 'POST_DRAW' * called after fields in the form have been populated (after POST_READ) End Case Return rtnValue
Copy/Delete
From the O4W WYSIWYG menu choose Copy/Delete.
Select the form name you want to copy. Enter the name of the form you want to create in the textbox provided and click the Copy button. To delete an existing O4W WYSIWYG Form, select the form name you want to delete and press the DELETE button.
Run
From the O4W WYSIWYG menu choose Run.
Select the name of the O4W WYSIWYG Form you want to run and press the Run button. Checking Run in mobile mode will launch the form utilizing mobile enabled controls. Checking Run in another tab will launch the form in the next tab on your browser.
Reset Defaults
- When using the WYSIWYG form designer, you are given the option to specify that any manual settings you provide for any of the element properties should become the default settings for that element type for that property going forward. For example, you may set the text field background color to green, and then check the “Make this the default” checkbox; any subsequent plain text fields that are created will default to having the background color set to green. You can reset the WYSIWYG form designer to its original defaults by choosing this option.