For new APEX developers, adding a page process condition can be a bit confusing at first when basing it on multiple buttons. This post will go through a scenario on how to easily use multiple buttons in a page condition.
The Setup
A classic example of having multiple buttons on a page is when you want to save or update a record. The Save button should only appear for new records, whereas the Update button should only appear for existing records. The catch is that when saving and updating the page you may need to run the same process.
The following setup highlights this classic example. Create a region in a page with two fields: P1_X and P1_Y. Then create three buttons: Save, Update, and Cancel. All three buttons should submit the page and an example of the page is shown below
Create the following page process:
Name: Update P1_Y
Process Point: On Submit - After Computations and Validations
Process: :P1_Y := :P1_X * 2;
The Problem
You'd like this process to run when both the Save and Update buttons are clicked. If you scroll down to the process's conditions area you'll notice that it has an option to restrict the process when a particular button is clicked (shown below).
As you can see you can only select one button from the list. At first glance the only option that you have to resolve the two button issue is to create a new process, which is a copy of the existing process, and set the condition to the other button. That doesn't necessarily make sense and can be an obvious maintenance nightmear.
The good news is that there is a very simple way to get around this issue. When you click a button it actually sets the REQUEST variable to the button name. The button name is defined in the button. For example the Save button's request is actually SAVE (shown below).
Going back to the original problem, and leveraging what we know about the REQUEST variable, you can modify the process's condition to have it run when either the Save or Update buttons are selected as shown below.
Note: They're other ways to use the REQUEST variable in the conditions section. This one highlights a very simple use.
Tuesday, December 13, 2011
Thursday, December 8, 2011
Moving the APEX Developer Toolbar
When you are developing an APEX application there may be certain situations (primarily depending on your page template) that require you to move the APEX toolbar from the bottom of the screen. The screen shot below shows such a case where there is content all the way to the end of the screen and the toolbar is preventing you from accessing/clicking on something at the bottom. If you try to click the last Edit button nothing happens since the toolbar is overlaying it. Note: I modified the page template to highlight this issue.
This doesn't occur very often but when it does there's a simple solution to move the toolbar from the bottom to the top of the screen. Run the following JavaScript code in your browser's console window and the toolbar will move to the top of the page.
If this happens a lot in development you could create a special button for the JavaScript code and add it as a dynamic action.
This doesn't occur very often but when it does there's a simple solution to move the toolbar from the bottom to the top of the screen. Run the following JavaScript code in your browser's console window and the toolbar will move to the top of the page.
//Note on older versions of APEX you'll need to check the toolbar's ID $('#apex-dev-toolbar').css({ top: 0, height: '22px' });Once at the top it will look like the image below. Note that the logout link (top right corner) is no longer clickable.
If this happens a lot in development you could create a special button for the JavaScript code and add it as a dynamic action.
Monday, December 5, 2011
apex_application.stop_apex_engine
Something that was upgraded in APEX 4.1 with little to no far fair was the addition of a new (supported) procedure called apex_application.stop_apex_engine. The apex_application.stop_apex_engine essentially stops the APEX engine and, as a result, will stop processing the rest of the page. It is most commonly used when forcing URL redirects from a page.
Before APEX 4.1 you could still use a similar feature however it was an unsupported variable in the apex_application package called g_unrecoverable_error.
I've included an example below of the before vs. after 4.1 ways to stop the APEX engine.
For those who have used the apex_application.g_unrecoverable_error variable in some of your applications you should go back and upgrade to the new procedure. For more information about the stop_apex_engine procedure please read the APEX documentation.
Thanks to Jason Long for posting the following comment about the differences between apex_application.g_unrecoverable_error and stop_apex_engine. Be sure to read it carefully because in the right conditions switching between the two calls can have significant impacts.
There appear to be a couple gotchas with simply replacing g_unrecoverable_error with stop_apex_engine.
1. If there is any PL/SQL code immediately following the g_unrecoverable_error it will still be executed. It looks like stop_apex_engine actually exits out of the routine.
2. It looks like stop_apex_engine will roll back any SQL inserts/updates/deletes that occur in the routine, where as g_unrecoverable_error allow them to be committed.
Before APEX 4.1 you could still use a similar feature however it was an unsupported variable in the apex_application package called g_unrecoverable_error.
I've included an example below of the before vs. after 4.1 ways to stop the APEX engine.
-- Pre-APEX 4.1 (not supported) ... owa_util.redirect_url('http://www.clarifit.com'); apex_application.g_unrecoverable_error:= true; -- End APEX session -- APEX 4.1 and above (supported) ... owa_util.redirect_url('http://www.clarifit.com'); apex_application.stop_apex_engine; -- End APEX session
For those who have used the apex_application.g_unrecoverable_error variable in some of your applications you should go back and upgrade to the new procedure. For more information about the stop_apex_engine procedure please read the APEX documentation.
Thanks to Jason Long for posting the following comment about the differences between apex_application.g_unrecoverable_error and stop_apex_engine. Be sure to read it carefully because in the right conditions switching between the two calls can have significant impacts.
There appear to be a couple gotchas with simply replacing g_unrecoverable_error with stop_apex_engine.
1. If there is any PL/SQL code immediately following the g_unrecoverable_error it will still be executed. It looks like stop_apex_engine actually exits out of the routine.
2. It looks like stop_apex_engine will roll back any SQL inserts/updates/deletes that occur in the routine, where as g_unrecoverable_error allow them to be committed.
Thursday, December 1, 2011
ClariFit From/To Date Picker Plug-in
In my previous post I discussed an issue about dynamic min and max dates using the APEX date picker. If you haven't read the article please take a few minutes before continuing.
At the end of my previous post I left off with the following question: How do you solve the dynamic min/max date issue? The answer is to use a new plugin that I created called ClariFit From To Date Picker. This is a free and open source plugin created as part of the ClariFit plugin set and is covered in detail in the book: Expert Oracle Application Express Plugins.
The plugin is an item plugin. Its options (shown below) are similar to the APEX date picker. The main difference is that instead of having Minimum and Maximum date attributes you now have Date Type and Corresponding Date Item attributes. The Date Type can either be a From or To date (i.e. min/max date). The Corresponding Date Item is the item name for the date picker that will determine the date's restrictions.
I've created a demo on plugins.clarifit.com. If you select a date in the From Date field (in this case 24-Nov-2011) then open the To Date date picker you'll notice that you can't select anything before 24-Nov-2011 as shown below.
The plugin also comes bundled with some nifty features that may not be visible at first but are really useful:
The plugin can be downloaded from apex-plugin.com.
At the end of my previous post I left off with the following question: How do you solve the dynamic min/max date issue? The answer is to use a new plugin that I created called ClariFit From To Date Picker. This is a free and open source plugin created as part of the ClariFit plugin set and is covered in detail in the book: Expert Oracle Application Express Plugins.
The plugin is an item plugin. Its options (shown below) are similar to the APEX date picker. The main difference is that instead of having Minimum and Maximum date attributes you now have Date Type and Corresponding Date Item attributes. The Date Type can either be a From or To date (i.e. min/max date). The Corresponding Date Item is the item name for the date picker that will determine the date's restrictions.
I've created a demo on plugins.clarifit.com. If you select a date in the From Date field (in this case 24-Nov-2011) then open the To Date date picker you'll notice that you can't select anything before 24-Nov-2011 as shown below.
The plugin also comes bundled with some nifty features that may not be visible at first but are really useful:
- Allows for different From/To date formats (i.e. they don't need to be the same).
- Built in validations:
- Validates that the input is a valid date
- Validates that From Date is less than or equal to the To Date
- Javascript Console instrumentation (run the page in debug mode and look at the console)
The plugin can be downloaded from apex-plugin.com.
Subscribe to:
Posts (Atom)