APEXblog.nl - Tips and Tricks

About This Blog:
I (Richard Weug) started this blog primary for myself to save all kinds of Apex tips and tricks in one place. To use it as a place to write down how I used some coding in my own projects, but also to copy and paste all kinds of articles I find on the Internet. (So I never have to wonder on what website did I read about??? When I see something interesting I collect the content so I have my own archive/knowlegde base.

View my profile on LinkedIn


Tips & Tricks


Process Message During Page Rendering

Written by Richard Weug on Thursday, 27 March 2014 14:44. Posted in Tips and Tricks


In this blog post I discussed how the processing message can be shown when we have a page process that may take a while to process.  Sometimes the delay may occur when the page is being rendered.  We may not want the user to begin doing anything on the page until the whole page is loaded and rendered.

This can be done by calling the apex.widget.waitPopup() function.  Edit the page definition and add javaScript to call the function to the Header Text.  

<script type="text/javascript">

We add it to the header text in hopes that the waiting functionality will be executed early in page rendering.

Once our page is loaded we need to remove the loading bar and enable the page.  In the page definition we can add some code to the "Execute when Page Loads" field of JavaScript section.

$(window).load( function() {



*** Please use at your own discretion.  The only apex.widget function included in the documentation is apex.widget.initPageItem(pName,pOptions).  The function described here is not documented (as far as I can tell) and may be changed at anytime.

( Oracle Application Express (APEX) 4.2.4 )

Original article written by:  Process Message During Page Rendering


Recognize your APEX dev, qa and prod environments

Written by Richard Weug on Tuesday, 25 March 2014 14:35. Posted in Tips and Tricks

Here is a very quick entry, mostly to document how I sometimes keep applications in dev and QA (or prod) apart.  Lately I’ve been working with development and QA applications that live in the same workspace and server. Dev would be in one schema and QA in a different one.  Sometimes it’s a little too easy to make a mistake. This simple technique helps me keep my sanity.

In dev I have a watermark that says development. The image below repeats all over the background.  Click here to download.


development.png Right click to save.

// this is for DEV only, and will set a "development" background image
$("body").css("background-image", 'url(wwv_flow_file_mgr.get_file?p_security_group_id=2246505718948672&p_fname=development.png)');
$("#container").css("background-image", 'url(wwv_flow_file_mgr.get_file?p_security_group_id=2246505718948672&p_fname=development.png)');

In qa or prod I make sure the developer toolbar is red.

 // this is for Developers only to make sure we know we're in QA/prod 
 $(function() { $("#apex-dev-toolbar").css("background-color", 'red'); });

How to use it?

The development.png image goes in the workspace images, available to all apps.  I like to place either snippet in the “Global Notification” field for the app.

Global Notification

Why there? I like being able to edit or remove this code from the application without actually changing the app. Plus it’s automatically added to all pages.  When you promote from QA to prod you could actually leave the snippet that changes the toolbar in place since it will only be displayed to developers that log in to the builder.

The end result with the watermark looks like this:

Development Environment

Development Environment

I like that the development image will show up for everybody using the application, not just developers. It also helps when a user forgets or doesn’t realize which system they are using.

The end result for the developer toolbar looks like this:

APEX Developer Toolbar in red

APEX Developer Toolbar in red

Final Note

The selectors for the development image may need to be adjusted to your application. ALL application will have the body tag, that one doesn’t need to change.  However, we will often have too much content on top of it to see the watermark.  That’s why I also add it to the #container  The #container id will work fine for Theme 26 (and other themes).  For Theme 25 you may want to change from #container to #uBodyContainer  Sometimes you’ll need to experiment a little.

The red toolbar technique will also work on APEX 5, but instead of #apex-dev-toolbar use #apexDevToolbar

APEX 5 dev toolbar

APEX 5 (EA) dev toolbar


Don’t (always) call v()

Written by Richard Weug on Monday, 24 February 2014 16:13. Posted in Tips and Tricks

Instead of calling a function, when you can get the same effect by accessing a documented PL/SQL variable, you should. For example:

v('REQUEST')     = APEX_APPLICATION.g_request
v('APP_ID')      = APEX_APPLICATION.g_flow_id
v('APP_PAGE_ID') = APEX_APPLICATION.g_flow_step_id
v('DEBUG')       = APEX_APPLICATION.g_debug

Execute PL/SQL in background

Written by Richard Weug on Sunday, 23 March 2014 16:09. Posted in Tips and Tricks

PL/SQL Logik in APEX zu platzieren ist etwas völlig Normales und findet nahezu überall täglich statt. Gelegentlich kommt es aber vor, dass aus APEX heraus solche PL/SQL-Logik angestoßen werden soll, die länger laufen wird. Hinterlegt man diese ganz normal als PL/SQL-Prozess im onLoad oder onSubmit-Bereich, so müsste der Anwender mit dem Browser solange warten, bis der Prozess durchgelaufen ist. Das kann für eine bis zwei Minuten noch eben akzeptabel sein (ein Hinweis ist unbedingt nötig), dauert es aber länger, so muss der PL/SQL-Prozess in den Hintergrund gebracht werden.


Public Check Authorization

Written by Richard Weug on Tuesday, 04 March 2014 16:03. Posted in Tips and Tricks

APEX Authorization Schemes are a very effective and simple way to restrict elements in our applications.  Once defined, these authorizations can be applied to the majority of elements in APEX: Pages, Regions, Items, Buttons, Processes, Branches, etc…

There are several ways to code them, it will depend on your needs, but ultimately they return TRUE or FALSE.  Is the user ADMIN or NOT ADMIN.  Say for example that we have a MYAPP_USER_ROLES table that stores ROLE_KEY and USERNAME columns. In this case, we could define an “ADMIN” Authorization Scheme of type “Exists SQL Query” that looks like this: