How to Handle User Responses in Oracle Forms Alert

In Oracle Forms, alerts are an effective way to communicate with users and prompt them for decisions. Unlike simple messages, alerts can have up to three buttons, allowing users to choose how they want to proceed. To build reliable applications, it is important not only to display alerts but also to handle the user’s response correctly. This ensures that the application behaves as expected based on the choice the user makes. In this article, you will learn how to capture responses from alerts, interpret button clicks, implement them in different scenarios, and follow best practices.

Understanding User Responses in Alerts

When you use the SHOW_ALERT built-in to display an alert, Oracle Forms pauses execution until the user clicks one of the alert’s buttons. The return value from SHOW_ALERT tells you which button was pressed.

Key points:

• The return value is a number (1, 2, or 3).
• It corresponds to ALERT_BUTTON1, ALERT_BUTTON2, or ALERT_BUTTON3.
• You must handle each possible return value to control the flow of the application.

Syntax for Capturing User Response

DECLARE
   alert_button NUMBER;
BEGIN
   alert_button := SHOW_ALERT('alert_name');
   
   IF alert_button = ALERT_BUTTON1 THEN
      -- Action for first button
   ELSIF alert_button = ALERT_BUTTON2 THEN
      -- Action for second button
   ELSE
      -- Action for third button (if exists)
   END IF;
END;

• alert_name → The name of the alert defined in the Form Builder.
• alert_button → Stores which button the user clicked.

Example 1: Exit Confirmation

A common scenario is confirming if the user wants to exit a form.

DECLARE
   alert_button NUMBER;
BEGIN
   alert_button := SHOW_ALERT('ALR_CONFIRM_EXIT');

   IF alert_button = ALERT_BUTTON1 THEN
      -- User chose "Yes"
      EXIT_FORM;
   ELSE
      -- User chose "No"
      MESSAGE('Exit cancelled.');
      MESSAGE(' ');
   END IF;
END;

Here:

• ALR_CONFIRM_EXIT has two buttons: Yes and No.
• If the user clicks Yes, the form closes.
• If the user clicks No, a message is displayed, and the user remains in the form.

Example 2: Delete Record Confirmation

Alerts are often used before deleting important data.

DECLARE
   alert_button NUMBER;
BEGIN
   alert_button := SHOW_ALERT('ALR_DELETE_RECORD');

   IF alert_button = ALERT_BUTTON1 THEN
      -- First button = Delete
      DELETE_RECORD;
      COMMIT;
      MESSAGE('Record deleted successfully.');
      MESSAGE(' ');
   ELSE
      -- Second button = Cancel
      MESSAGE('Delete action cancelled.');
      MESSAGE(' ');
   END IF;
END;

In this case:

• The alert has Delete and Cancel buttons.
• Based on the response, the system either deletes the record or cancels the operation.

Example 3: Handling Three Options

Sometimes, you may want to present multiple choices to the user.

DECLARE
   alert_button NUMBER;
BEGIN
   alert_button := SHOW_ALERT('ALR_OPTIONS');

   IF alert_button = ALERT_BUTTON1 THEN
      MESSAGE('Option 1 selected.');
   ELSIF alert_button = ALERT_BUTTON2 THEN
      MESSAGE('Option 2 selected.');
   ELSE
      MESSAGE('Option 3 selected.');
   END IF;
   MESSAGE(' ');
END;

Here:

• The alert has three buttons (e.g., Option 1, Option 2, Option 3).
• Each button click triggers different logic.

Best Practices for Handling User Responses

1. Always check the return value
   • Never ignore the result of SHOW_ALERT, as the application may behave unpredictably.
2. Use meaningful button labels
   • Replace generic "Yes/No/Cancel" with descriptive labels like "Save", "Discard", "Exit".
3. Provide feedback to users
   • Display confirmation messages for actions like delete, save, or cancel.
4. Handle all possible responses
   • Even if you expect only one choice, code for all possible buttons.
5. Avoid unnecessary alerts
   • Use alerts only when user decisions are needed. For simple messages, use MESSAGE.

Common Mistakes to Avoid

• Not handling all button clicks → Can leave the application in an undefined state.
• Overusing alerts → Too many alerts can frustrate users.
• Using alerts for validation → Validation should be handled using triggers like WHEN-VALIDATE-ITEM, not alerts.
• Forgetting to commit or rollback → Always finalize database actions after the user confirms.

Benefits of Properly Handling Alerts

When used correctly, alerts enhance both usability and system safety:

• Ensures critical actions are confirmed before execution.
• Provides clear control flow for the user.
• Prevents accidental data loss by requiring confirmation.
• Makes the application more professional and user-friendly.

Conclusion

Handling user responses in Oracle Forms alerts is an essential skill for developers. By using the SHOW_ALERT built-in and capturing which button the user clicks, you can safely control form navigation, data deletion, and other critical operations.

With meaningful button labels, proper feedback, and careful handling of return values, alerts become powerful tools for creating user-friendly Oracle Forms applications that prevent mistakes and guide users through the right decisions.