Bringing Ideas Together

I’m currently enjoying 4 days in Austria, whilst I’d love to be on holidays skiing this trip is all business, and I wouldn’t want it any other way. Why? Sounds crazy I know… but today is a special day and destined to happen.

Today I’m pleased to announce that I’m working with Peter Raganitsch, arguably the most knowledgeable and best APEX developer outside of the APEX development team. Together we’re combining our efforts to build some amazing software for APEX which is going to transform your APEX applications into something amazing without changing the way you develop them.

For now my lips are sealed on the details but watch this space as we’ll be making a big announcement to the APEX community in the near future.


APEX – Tabular Form Validation Issues/Bugs

Today seems to be going from bad to worse. Not only am I fighting a number of IE6 issues with APEX and CSS I’ve run into a couple of issue with tabular form validations in APEX 4.1.

Please Note: the workarounds which I’m about to describe in this post are not supported by the APEX team and that they may not work in future versions of APEX. Please proceed with caution. I take no responsibility for any negative outcomes from this.

Problem 1

The first issue I encountered occurs when I have line breaks in a text area in a tabular form and a tabular form validation error is raised. The javascript error displayed in the console on page load is “unterminated string literal”. To make matters a little more worse it stops all other dynamic action javascript from running which includes my page load mask, so the end result is a never ending page load mask.

To circumvent the problem I created a “PLSQL Function Returning Boolean” validation which runs after all others validations and strips the line breaks for the first two columns e.g.

  FOR i IN 1.. apex_application.g_f01.count LOOP
   apex_application.g_f01(i) := regexp_replace(apex_application.g_f01(i), '('||CHR(10)||'|'||CHR(13)||')','');
   apex_application.g_f02(i) := regexp_replace(apex_application.g_f02(i), '('||CHR(10)||'|'||CHR(13)||')','');

The point to note is that our validation always returns TRUE as we’re not actually validating anything, just running some PLSQL to strip the line breaks. I find this hack quite useful in certain situations, since we can’t use computations as they are bound to page and application items. In order to work out which f0x array you need to strip the EOL characters from, use firebug or an equivalent DOM inspector.

Now if you want to keep line breaks in your tab form columns and only strip them to avoid validation errors then set a condition on this validation to “Inline Validation Errors Displayed”.

Problem 2

The next issue I encountered was that POPUPKEY LOV’s display value was not set on validation error, however the actual value is. The workaround again is to use the same technique as described above with a little more code and after creating a protected hidden page item to hold the javascript which will run on page load and set the popupkey display values:


Please Note: in the above code there is an intentional space between the colon and item name because wordpress is replacing these with smilies.

In the above PLSQL, f04 is our display value for the popup key LOV and f03 is our hidden return value. We need to perform an extra step and do a lookup of the return value in the code. This is because the actual display value is a disabled input item and never submitted with the HTML form so we can’t access the f04 array in PLSQL (it’s part of the HTML spec). Also in your label lookup function make make sure you JSON escape the label value to avoid any javascript errors like the APEX one described in the first problem above.

The next step is that we create one more fake validation which is the last in out list (i.e. has the highest display sequence). It is a “PLSQL Function Returning Error Text” validation which has the following PLSQL:


This will append our javascript unescaped to the validation error messages. Again, ensure you set a condition on this validation to “Inline Validation Errors Displayed” as we only ever want to output the javascript when a validation failure has occurred. The reason why we use another fake validation is to ensure that the javascript is only outputted once and also so that the popupkey display value is always set for any validation failure. The other reason is that we cannot define javascript within page items and use substitution strings in the error messages, as APEX will escape them and they will appear as plain text in your error message.

In the end it’s a pretty heavy and ugly solution for something which is expected to be built-in within APEX, but the bright side is that APEX is still flexible enough for us to code workarounds when there’s bugs within the product.


APEX – Textarea Resizer width issue in IE

Currently I’m developing an application in APEX 4.1 for a target browser of IE6. One of the latest problems I encountered was with the textarea resizer not extending to the full width of the textarea. This was due to APEX automatically adding an inline style to the FIELDSET tag with a very small width. To work around the issue I added the following style to my IE specific stylesheet to overcome the issue:

fieldset.textarea { width:auto !important; }

Luckily the !important flag will override inline styling. Here’s what the symptom looks like:

Pages ... 1 2