VSCode UI Editor

Quick Start

VSCode UI designer — Quick Start

Design, inspect and evolve OpenEdge ABL user interfaces without leaving VS Code. <br/> It provides a visual designer and toolbox workflow for API4UI projects, with OpenEdge ABL as the current supported language.

Prerequisites

Install

Install API4UI - UI Designer & Toolbox from the VS Code Marketplace or from the .vsix file.

Configure your project

API4UI works best when your workspace contains an openedge-project.json file that describes your OpenEdge project structure.

Project scope example — add to openedge-project.json:

{
  "name": "MyOpenEdgeProject",
  "dbConnections": [
    {
      "name": "sports2020",
      "connect": "-db sports2020 -H localhost -S 10001"
    }
  ],
  "propath": [
    {
      "path": "src"
    }
  ]
}

Designer assets — API4UI creates and uses project metadata under .api4ui/ when you work with toolbox components and generated UI metadata.

Open API4UI

Three ways to launch it:

1. Right-click a .w file in the Explorer and choose 🎨 Open in API4UI designer.

The first launch may take a few seconds while the designer webview and project metadata load.

What you can do

• Open .w UI source files in the visual designer.
• Design layouts with drag-and-drop editing.
• Modify the generic UI model instead of editing generated structure by hand.
• Generate / merge changes back into OpenEdge ABL UI code while preserving custom logic.
• Create new forms, dialogs and related UI artifacts from wizard-driven commands.
• Configure project settings, component metadata and designer behavior inside VS Code.
• Prepare your project for future AI-assisted UI editing workflows on the API4UI roadmap.

Demo

Interface Overview

Interface Overview

Overview

This guide explains the main parts of the VSCode UI designer interface.

The overall layout is built around a visual editing workflow, helping you move from opening an OpenEdge ABL UI file to selecting widgets, adjusting properties, inspecting events, and writing the updated model back to native code.

Header Area

The header area appears at the top of the designer.

From here, you can:

• see the current workspace or project context
• see the currently opened file name
• understand which editor tab or designer session you are working in

This area helps keep you oriented while working inside a larger OpenEdge project.

Left Toolbar Area

The left toolbar appears along the left side of the designer surface.

This area lets you:

• start or trigger common designer actions
• switch between selection and view-related tools
• zoom in or zoom out on the design surface
• fit or reset the canvas view while editing complex layouts
• access undo and redo style editing actions

This keeps the most common canvas commands close to the design surface.

Design Canvas Area

The design canvas area is the central workspace of the interface.

This area lets you:

• view the current OpenEdge window or frame layout visually
• select widgets such as buttons, frames, and other UI elements
• reposition and resize widgets directly on the grid
• understand spatial relationships between controls in the form
• work with the generic UI model through direct manipulation

This is the main editing area where visual changes are made.

Widget Selection Overlay Area

When a widget is selected, a compact selection overlay appears directly on the canvas.

Component Selection:

Layers:

From here, you can:

• confirm which widget is currently selected
• access quick actions for the selected widget
• add or adjust nearby layout relationships
• remove widgets when appropriate

This makes common widget-level actions available without leaving the canvas.

Properties and Events Panel Area

The properties and events panel appears on the right side of the interface.

This area lets you:

• view the name and type of the current selection
• search through editable settings using the filter field
• switch between the Properties tab and the Events tab
• update appearance, layout, interaction, data, and label settings
• inspect or edit event-related behavior for the selected component

This is the main detailed configuration area for the selected widget.

Property Groups

Inside the right-side panel, settings are grouped into collapsible sections.

Typical groups include:

• Advanced
• Appearance
• Custom Lists
• Data
• Frame Options
• Interaction
• Layout
• Menus
• Text & Labels

From here, you can:

• focus on one category of settings at a time
• reduce noise by collapsing sections you do not need
• make precise changes without scanning one long property list

This organization keeps the editor manageable even for widgets with many configurable properties.

Bindings Area

The bindings area appears near the bottom of the designer.

This area lets you:

• see where binding-related interactions are managed
• drag an API or binding source into the editor workflow when supported
• understand where data-oriented UI wiring belongs in the interface

This area supports the broader model-driven workflow around UI structure and connected data.

Properties Guide

Properties Guide

Overview

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

The Properties tab is where you refine the selected widget after placing it on the design canvas. It gives you a structured way to change layout, appearance, text, interaction, and other widget-specific settings without editing the underlying OpenEdge ABL code by hand.

Before You Start

To work with properties:

• 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 Properties tab is active rather than the Events tab

The property editor always works on the currently selected widget.

Selecting a Widget

Before changing any property, first select the widget you want to edit.

You can do this by:

• clicking the widget directly on the design canvas
• selecting a frame or container before editing nested layout-related settings
• confirming the selection from the widget label shown in the right-side panel

Once a widget is selected, the Properties panel updates to show the settings that apply to that specific object.

Finding a Property

The property panel includes a filter field near the top.

Use this when you:

• already know the name of the property you want to change
• want to narrow a long list of settings quickly
• want to confirm whether a selected widget supports a specific property

This is usually the fastest way to find a single setting in a large property list.

How Property Groups Work

Properties are organized into collapsible sections.

This helps you:

• focus on one kind of setting at a time
• hide groups that are not relevant to the current change
• avoid scanning the entire panel for every edit

Typical groups include:

• Advanced
• Appearance
• Custom Lists
• Data
• Frame Options
• Interaction
• Layout
• Menus
• Text & Labels

Not every widget will show every group. The available groups depend on the selected object type.

Appearance Properties

The Appearance group is typically used for the visual look of a widget.

This group may include settings related to:

• colors
• fonts
• visibility-related presentation settings
• stylistic options that affect how the widget is rendered

Use this group when you want to change how a control looks without changing its role in the layout.

Layout Properties

The Layout group is typically where size and position changes belong.

Use this group when you want to:

• move a widget
• resize a widget
• adjust layout unit related behavior
• fine-tune how the widget fits inside a frame or container

This is one of the most commonly used property groups because it controls how the UI is arranged on the design surface.

Text and Label Properties

The Text & Labels group is used for visible text shown to the user.

Use this group when you want to change:

• captions
• labels
• displayed text
• user-facing wording attached to the selected widget

This is usually the right place for common edits such as renaming a button label or changing text shown in the interface.

Interaction Properties

The Interaction group controls how the widget behaves during user interaction.

This group may include settings related to:

• enabled or disabled behavior
• focus-related behavior
• input-related configuration
• other interaction-specific rules supported by the selected widget

Use this group when the behavior of the control matters more than its visual styling.

Data Properties

The Data group is used for widgets that have a data-oriented role.

Use this group when you want to work with:

• field-related settings
• data binding related values when supported
• properties that affect how the widget connects to data in the UI model

This group is especially relevant for controls that represent or display business data rather than only static content.

Frame Options and Container Settings

When the selected widget is a frame or container, you may see Frame Options and related container-specific settings.

Use these settings when you want to:

• configure the frame itself rather than a child widget
• adjust frame behavior or presentation
• tune container-level layout behavior

If you are editing the structure of a form, this is often the first place to check after selecting the frame.

Menus and Custom Lists

Some widgets expose Menus or Custom Lists groups.

Use these groups when you need to work with:

• menu-related configuration
• list-driven options
• widget-specific collections or structured values

These groups are more specialized and may only appear for certain widget types.

Advanced Properties

The Advanced group is for settings that are useful but less common in basic editing scenarios.

Use this group carefully when you need to:

• fine-tune widget behavior beyond standard visual editing
• set less frequently used OpenEdge-related properties
• adjust details that are important for generated output or runtime behavior

If you are unsure about a setting, make small changes and validate the result after saving.

Common Editing Examples

Typical property changes include:

• Change button text
  • select the button
  • open Text & Labels
  • update the visible caption or label value
• Move a frame
  • select the frame on the canvas
  • open Layout
  • adjust the relevant size or position values
• Resize a control
  • select the widget
  • open Layout
  • update width, height, or related sizing properties
• Change visual styling
  • select the widget
  • open Appearance
  • update the relevant presentation settings

Good Working Habits

When editing properties, it helps to:

• change one thing at a time when testing unfamiliar settings
• confirm that the correct widget is selected before editing
• use the filter field instead of scrolling through all groups
• save and validate your result after meaningful changes
• pay extra attention when editing frame-level properties because they can affect multiple child widgets

These habits make it easier to understand which change produced which result.

What to Verify After Changing Properties

After changing properties, it is useful to verify:

• the widget still looks correct on the canvas
• the layout still makes sense relative to nearby controls
• the selected values match the intended behavior
• the generated or written-back ABL result still reflects the intended UI change

This is especially important for layout, frame, and advanced property edits.

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.