Designing the Procedure Logic › GUI Event Processing › Windows and Window Controls That Signal Events › SCROLL TOP and SCROLL BOTTOM GUI Events

SCROLL TOP and SCROLL BOTTOM GUI Events

A search is performed on a list window to limit the number of rows returned from the database, however sometimes the number of rows returned exceeds the cardinality of the group view.

The SCROLL TOP and SCROLL BOTTOM events allow processing to retrieve the next group of data in either direction.

When the SCROLL TOP EVENT is triggered, the following actions occur:

• Scroll indicator is moved to the top of the scroll bar.
• Up arrow key is pressed.
• First row in the group view is displayed.

When the SCROLL BOTTOM event is triggered, the following actions occur:

• Scroll indicator is moved bottom of the scroll bar.
• Down arrow key is pressed.
• Last row in the group view is displayed.

For example, the user requests all the customers with addresses in California be sorted by last name. There are 15,042 customers in California.

The group view containing the customers has a cardinality of 500.

After the user scrolls through the first 500 customers, a SCROLL BOTTOM event is triggered to retrieve the next 500 customers in last name order.

If the user wants to scroll back up to the first 500 customers, they move the scroll indicator to the top of the scroll bar. The SCROLL TOP event is triggered, and the previous 500 customers are retrieved in last name order.

Note: If new customers were added in the first 500 group, the first record is not displayed in the previous group of 500 customers.

The user is not able to look at the last window of data by moving the scroll indicator to the bottom of the scroll bar since this action triggers the SCROLL BOTTOM event (the same is true for the SCROLL TOP event). Even using the up and down arrow keys, the user may trigger a SCROLL TOP or SCROLL BOTTOM event unintentionally.

There are three scrolling alternatives:

• Retrieve only half of the number of records that are allowed in a list. This is the recommended alternative.

  For example, if the group view has a cardinality of 500, have the scroll bottom event retrieve the next 250 and append them to the previous 250, displaying the last row before the fetch at the top of the list window.

  This lets the user stay in the context of where they are working in the list. When they scroll to the bottom of the list, the next group is retrieved and appended to the first group. Then the scroll indicator bounces from the bottom to the middle of the scroll bar.

  If the user wants to scroll backwards from this point, the query does not have to be re-executed until the user scrolls to the top of the previous 250 records. If that happened, a Scroll Top event is triggered to retrieve the previous 250 records. The scroll indicator moves to the middle of the scroll bar, and the first row before the fetch is displayed at the top of the window.

• Provide More buttons in each direction, one for previous group and another for next group. The More buttons are enabled as long as data exists in either direction outside the current group view of the data.

  The SCROLL TOP and SCROLL BOTTOM events are not used, except perhaps to enable the More buttons if there is more data.

  If the user scrolls to the bottom of the list, and there is more data, the More button is enabled. When the user selects the button, the next group or half group of data is retrieved.

• Implement either of the previous alternatives without SCROLL TOP.

  SCROLL BOTTOM is used along with refresh to populate the first group view of the list.

  This avoids dealing with the complexity of SCROLL TOP processing.