Skip to main content

Replacing Format Masks with Custom JavaScript Number Formatting in APEX

 In Oracle APEX, the Amount page item is configured as a Number field with a format mask, while the corresponding backend database column (AMT) is defined as a NUMBER data type.

During runtime, APEX applies the format mask at the session state level, resulting in values that include thousand separators (commas).

When the session value is persisted to the database, this formatted string causes a data type conversion error, since the AMT column expects a pure numeric value.

To handle this, developers typically apply the TO_NUMBER() conversion function in PL/SQL processes to strip formatting before DML operations.

This ensures data integrity and prevents ORA-01722 (invalid number) errors during inserts or updates.

Instead of using a format mask, we can apply below JavaScript code on the global page and call it wherever needed.

function setformatAuto(input) {

    const formatter = new Intl.NumberFormat('en-IN', {

        currency: 'INR',

        minimumFractionDigits: 2

    });

    // Check if input is an APEX page item

    if (apex.item(input)) {

        var val = apex.item(input).getValue();

        if (val !== '') {

            var reslt = formatter.format(val).replace(/\D00$/, '');

            apex.item(input).setValue(reslt, '', true);

        }

    } else {

        // Treat input as a selector for HTML elements

        $(input).each(function() {

            var val = $(this).text();

            if (val !== '') {

                var reslt = formatter.format(val).replace(/\D00$/, '');

                $(this).text(reslt);

            }

        });

    }

}

If the user expects the mask to appear while entering the value, call the function on custom attribute section like below.

onkeyup="setformatAuto(this);"

Comments

Popular posts from this blog

APEX - Tip: Fix Floating Label Issue

Oracle APEX's Universal Theme provides a modern and clean user experience through features like floating (above) labels for page items.  These floating labels work seamlessly when users manually enter data, automatically moving the label above the field on focus or input.  However, a common UI issue appears when page item values are set Dynamically the label and the value overlap, resulting in a broken and confusing user interface. once the user focuses the affected item even once, the label immediately corrects itself and displays properly. When an issue is reported, several values are populated based on a single user input, causing the UI to appear misaligned and confusing for the end user. Here, I'll share a few tips to fix this issue. For example, employee details are populated based on the Employee name. In this case, the first True Action is used to set the values, and in the second True Action, paste the following code setTimeout(function () {   $("#P29_EMAIL,#P29_...

Oracle APEX UI Tip: Display Page Title Next to the APEX Logo

In most Oracle APEX applications, every page has a Page Title displayed at the top. While useful, this title occupies vertical space, especially in apps where screen real estate matters (dashboards, reports, dense forms). So the goal is simple: Show the page title near the APEX logo instead of consuming page content space. This keeps the UI clean, professional, and consistent across all pages. Instead of placing the page title inside the page body:         ✅ Fetch the current page title dynamically         ✅ Display it right after the APEX logo         ✅ Do it globally, so it works for every page All of this is achieved using:         ✅ Global Page (Page 0)         ✅ One Dynamic Action         ✅ PL/SQL + JavaScript Simple, effective, and reusable. 1️⃣ Create a Global Page Item On Page 0 (Global Page), create a hidden item:      P0_PAGE_TITLE This item wi...

Building a Custom Debug Package for Oracle APEX Using PL/SQL

While developing Oracle APEX applications, debugging page processes and backend PL/SQL logic can be challenging—especially when values are lost between processes or execution flow is unclear.  Although DBMS_OUTPUT is useful, it doesn’t work well inside APEX runtime. To solve this, I built a custom PL/SQL debug Package that logs execution flow and variable values into a database table.  This approach helps trace exactly where the code reached, what values were passed, and whether a block executed or not - even inside page-level processes and packaged procedures Why a Custom Debug Package? Works seamlessly inside Oracle APEX page processes Persists debug information even after session ends Helps trace execution flow Captures runtime values Can be turned ON/OFF dynamically Does not interrupt business logic The Package consists of:- Debug Table                         -  Stores debug messages Sequence ...