Dynamic Help Text in Oracle APEX Based on a Select List Value

If you have built enough Oracle APEX forms, you had probably ran into a situation where a single, generic help text just doesn't cut it for a form item. The user needs context, and that context changes depending on what they've already selected elsewhere on the page. That's exactly the problem I hit recently, and here documented in the approach i took.

The Problem

I had a form page with two fields:

• P26_VEHICLE_TYPE_ID - a select list for vehicle type

• P26_VEHICLE_NUMBER - a text input for the vehicle registration number

Here's the catch: vehicle number formats in My country(and in many countries) vary depending on the type of vehicle. A motorcycle has a different plate format from a Car or a Pickup truck. If I put a single static help text under the vehicle number field, something like "Enter your vehicle number" then it would be technically correct and practically not that nice to look at from the users pov (or may be you are a perfectionist:).

this didn't feel right. A good form should guide the user, not make them guess.

What APEX Gives You to work with

When you set a Inline Help Text on a Page Item in APEX, it renders as a <span> element just below the input field. The ID APEX generates for it follows a predictable pattern:

{ITEM_NAME}_inline_help

So for P26_VEHICLE_NUMBER, the span in the DOM would be:

P26_VEHICLE_NUMBER_inline_help

This is what we're going to target. finding the element APEX already renders and updating its content dynamically.

The Approach

The plan is Direct:

1. Add a Dynamic Action on P26_VEHICLE_TYPE_ID that fires on Change
2. Read the selected value
3. Look it up in a value-to-format mapping
4. Update the help text span accordingly

No PL/SQL. No AJAX calls. No page refresh. Just a small, focused piece of JavaScript running client-side.

Setting Up the Dynamic Action

In your APEX page, right-click on P26_VEHCILE_TYPE_ID in the Page Designer tree and select Create Dynamic Action.

• Name: When_produc_id_changed (or whatever that makes sense to you)

• When → Event: Change

• When → Item(s): P26_VEHCILE_TYPE_ID

For the True Action, add a Execute JavaScript Code, then paste in the code after customizing it according to your specific wants.

The JavaScript

// Get the selected value from the vehicle type select list
var selectedValue = $v('P26_VEHCILE_TYPE_ID');

// Get the inline help span APEX rendered for the vehicle number field
var spanElement = document.getElementById('P26_VEHICLE_NUMBER_inline_help');

// Map each vehicle type ID to its expected number format(s)
var valueTextMap = {
  '21': 'A1A2345 / A0A2345',
  '22': 'C3A2345 / C4A2345',
  '25': 'B1A2345',
  '27': 'C1A2345 / C2A2345'
};

var defaultText = 'Select a vehicle type';

// Update the span content based on what was selected
if (spanElement) {
  if (valueTextMap[selectedValue]) {
    spanElement.textContent = 'Eg: ' + valueTextMap[selectedValue];
  } else {
    spanElement.textContent = 'Eg: ' + defaultText;
  }
}

A few things worth calling out:

• $v() is APEX's shorthand for getting a page item's value itis cleaner than document.getElementById(...).value

• The valueTextMap object is your source of truth. Add, remove, or update entries as your vehicle types grow or change

• The fallback defaultText handles the case where nothing is selected yet, or the selected value doesn't have a mapping

Seeing It in Action

Once you save and run the page, selecting a vehicle type from the dropdown should immediately update the help text below the vehicle number field no submit, no reload needed.

For example:

• Select a vehicle type mapped to '22' → help text shows Eg: C3A2345 / C4A2345

• Select one mapped to '25' → help text shows Eg: B1A2345

• Clear the selection → help text falls back to Eg: Select a vehicle type

Why This Works Well

What I like about this approach is how little it relies on. There's no Dynamic Action calling the server, no hidden item being submitted, no complicated condition logic spread across multiple actions. The mapping lives right in the JavaScript, which makes it easy to read and easy to update.

It also uses something APEX already gives you, the inline help span. rather than injecting custom DOM elements that could break on upgrades or theme changes.

If your vehicle types are driven by a lookup table and the IDs are stable (which they usually are in a well-structured schema) or you have a similar situation like my own example , this pattern holds up well long-term.

Adapting This for Your Own Use Case

The core pattern here isn't specific to vehicle numbers. Anywhere you have:

• A select list whose value changes the meaning or format of another field

• And you want the user to understand that without reading a manual