Events Guide

Events Guide

Overview

This guide explains how to work with the Events tab in the VSCode UI designer.

The Events tab is where you inspect and adjust event-related behavior for the currently selected widget. It helps you understand how user actions in the visual interface relate to generated or preserved OpenEdge ABL event logic.

Before You Start

To work with events:

• open a supported OpenEdge ABL UI file in the designer
• select a widget on the design canvas
• open the right-side panel
• make sure the Events tab is active rather than the Properties tab

The events editor always works on the currently selected widget.

Selecting the Right Widget

Before changing an event, first select the widget you want to inspect.

You can do this by:

• clicking the widget directly on the design canvas
• selecting the correct frame or container before checking frame-level behavior
• confirming the current selection in the right-side panel header

Once a widget is selected, the Events tab updates to show the event-related settings that apply to that object.

What an Event Means

In this interface, an event represents behavior that is triggered by something that happens in the UI.

Typical examples include:

• a user clicking a button
• a control receiving focus
• a value being changed
• a widget reacting to interaction at runtime

In OpenEdge ABL terms, these behaviors are typically related to event handling logic that the designer must preserve or regenerate correctly.

How the Events Tab Works

The Events tab is part of the same right-side panel used for properties.

From here, you can:

• inspect which event-related settings are available for the selected widget
• review event-oriented configuration without searching through general properties
• focus on behavior instead of appearance or layout
• prepare event changes while staying inside the visual editing workflow

Not every widget will expose the same event options. The available event settings depend on the selected object type.

When to Use Events Instead of Properties

Use the Events tab when you want to change behavior.

Typical cases include:

• deciding what should happen when a control is interacted with
• reviewing whether a widget has event-related logic
• checking widget behavior rather than visual appearance
• working with generated or preserved event structure in the UI model

Use the Properties tab instead when you want to change text, size, layout, colors, or other non-event settings.

Common Event Scenarios

Typical event-related work includes:

• Button behavior
  • select the button
  • open Events
  • inspect the available action-related event settings
• Frame-level behavior
  • select the frame rather than a child control
  • open Events
  • review any frame-specific runtime behavior that applies at container level
• Widget interaction review
  • select the control
  • open Events
  • confirm that the current event configuration matches the intended user interaction

Good Working Habits

When editing events, it helps to:

• confirm that the correct widget is selected before making changes
• change one event-related setting at a time when testing behavior
• validate the result after meaningful edits
• be extra careful when editing container or frame-level behavior
• compare the intended runtime behavior with what the UI should actually do for the user

These habits reduce the chance of making a behavior change that is harder to notice than a visual change.

What to Verify After Changing Events

After changing event-related settings, it is useful to verify:

• the correct widget or frame was edited
• the intended behavior is still clear from the UI model
• the written-back ABL result still reflects the expected event behavior
• no unrelated visual or structural changes were introduced while editing behavior

This is especially important for widgets that already contain existing application logic.

Events and Write-Back

Event changes are more sensitive than many property changes because they affect behavior rather than only presentation.

When working with the Events tab, keep in mind:

• event-related edits should be reviewed carefully after saving
• existing application behavior should still make sense after write-back
• preserved OpenEdge ABL logic should be checked whenever a change affects runtime interaction

This helps reduce the risk of changing what the interface does when the user interacts with it.