Button cannot be deleted as a process referencing this button exists

After some weeks of vacation, i was almost to the point of shooting a classical off-topic posting, in spite of all those blogtiquette rules that advise the savvy blogger of not doing so.

Luckily enough, i just found a sort of bug in Apex 3.0.1 (and earlier i believe), regarding the deletion of a button.

At any rate, before delving into the main topic, let me point out that this blog entry is heralding a new era for me, as it is the first one written on an Apple Mac, so now you can enroll me in the list of "ex-PC users" ;-)

And now for the main topic.

1. Create a blank page in an Apex application
2. Create a blank html region.
3. Create a button and call it SUBMIT.
4. Create an After Submit process of any kind and make it conditional on the SUBMIT button.
5. Change the process type to Before Header.
6. Try to delete the button:

Button SUBMIT cannot be deleted as a process referencing this button exists

If you open up the process definition page, you won't be able to see any properties telling that the button is linked to the button, but this is normal as it doesn't make sense to link a Before Header process to a button.
On the other hand, if you open the grid view for the process, you will actually find the missing property and it will report that button SUBMIT is attached to the process.
At this point you can clear the relationship from the grid view or alternatively change the process type back to After Submit and then clear the property from there.

And now i can go back to explore this exciting Mac world.

Forcing apex item buttons to do what you want

If you tried with little success to attach some javascript code to an Apex item button (not a region button, that's a piece of cake...) , it may console you to know that i have been in the same situation for some time.

I wanted to catch button clicks and display one of those classic, annoying pop up messages asking "do you really really really want to delete this stuff?"

With a normal region button it's pretty easy, although it's not so straightforward.

You need to go to the button property called optional URL redirect and pick the value URL and put something like:

javascript:confirmDelete('Press OK to delete the selected rows',
'MULTI_ROW_DELETE');

in the URL target attribute.

Unfortunately item buttons don't come with the same feature, so one starts wondering about some fancy way of hacking the system.

Luckily enough, if you opt for a template based button, there is a property called Attributes where apparently you can put your stuff.
But this is just the half of the moon.
Because the button template you are using might not include a #BUTTON_ATTRIBUTES# substitution string in its definition (as suggested in Apex on-line help), so, whatever you put there, it won't work because it will be left out.

So, to get to the other side of the moon, you need to customize the template button, or better, to make a copy of an existing one and customize the duplicate, just in case you don't want to mess up the entire application.

Here is how i did it:

first i picked the Button, Alternative 2 template (may be it doesn't exist such template in the theme you're currently using, so pick a different one) and copied it, using the built-in copy feature.
With much fantasy i renamed it to Button, Alternative 2, Custom.

Here is the template before i started hacking it:

<table class="t1ButtonAlternative2"
cellspacing="0" cellpadding="0"
border="0"  summary="">
<tr>
<td class="t1L">
<a href="#LINK#">
<img src="#IMAGE_PREFIX#themes/theme_1/button_alt2_left.gif"
alt="" width="11" height="20" />
</a>
</td>
<td class="t1C">
<a href="#LINK#">#LABEL#</a>
</td>
<td class="t1R">
<a href="#LINK#">
<img src="#IMAGE_PREFIX#themes/theme_1/button_alt2_right.gif"
width="11" height="20" alt="" />
</a>
</td>
</tr>
</table>

As you see there was no trace of the #BUTTON_ATTRIBUTES# mentioned above, so i changed it as follows:

<table class="t1ButtonAlternative2"
cellspacing="0" cellpadding="0"
border="0"  summary="">
<tr>
<td class="t1L">
<a href="#BUTTON_ATTRIBUTES#">
<img src="#IMAGE_PREFIX#themes/theme_1/button_alt2_left.gif"
alt="" width="11" height="20" />
</a>
</td>
<td class="t1C">
<a href="#BUTTON_ATTRIBUTES#">#LABEL#</a>
</td>
<td class="t1R">
<a href="#BUTTON_ATTRIBUTES#">
<img src="#IMAGE_PREFIX#themes/theme_1/button_alt2_right.gif"
width="11" height="20" alt="" />
</a>
</td>
</tr>
</table>

This template will work well provided you perform the following settings in the button definition:

• Pick Template based button as Style attribute
• Pick Button, Alternative 2 Custom (or whatever is in your case) as Template attribute
  
• Put the following text in the Attributes property

  javascript:confirmDelete('message to user','request string');

• Clear the content of the property Button Request Value
• Set the property Button Request Source Type to Always null

Happy scripting.

Apex ghost buttons after deleting region

Just a quick repost of the forum entry, plus some fancy screenshots.

A region containing some buttons defined as button items, not normal region buttons.
Here is a screen dump where item buttons are highlighted.



And here is how they look in the real page.


If you delete the region without checking the delete corresponding buttons and delete corresponding items, you'll get ghost buttons.


The two buttons highlighted in yellow above, are normal buttons and they do show up, although they are classified as buttons with no regions. If you go to the button grid editor page, you'll see that instead of the region name, there is the old region id, an internal counter i presume.

What it's not showing up there are those two Raggruppa and Assegna buttons.

You don't see them in the buttons list grid page or in the items list grid page, nevertheless they are lingering in the upper side of your application's page.


I thought i could easily recreate the region and reassign old items and buttons to it without having to recreate them, however while normal region items become so called page items after deleting the region and they can be easily reassigned, item buttons do not show up in any definition list, so you can't re-link them.

In order to fix the page i had to tamper with the page export.
First i exported the page, then i manually deleted the offending entries in the .sql file and reimported it. Finally i recreated the buttons from scratch.

Note that if you had page processes triggered by the old buttons, they will need to be fixed as well. That is why normally i prefer to define conditions based on the REQUEST system variable than basing on the button's name.

But i really would like to figure out how to manually link an item to a certain region in case i need it again in the future.

----

Edited on january 10:

I need to amend my previous statement as Scott pointed out in the Apex forum that actually those two "missing" items are still there in the page items section and for some reason i could not spot them in the plethora of items clogging my page.

So, what started as a bug initially, needs to be correctly downgraded to a quirk, because i am still convinced that if they are buttons, they should show up in the buttons list, not just as items in the page level items section.

So, if you can't find your buttons, triple check the page items sections, they ended up over there for sure.

The beta tester and the ghost bug

It's been a long debugging day today.
Everything started yesterday evening, when i got a phone call of an employee saying:
"I entered 50 records in the afternoon, but i just logged in the application now and they are all gone!"

So, i logged in to see what's wrong and oops! No data to display, nothing, nada de nada.

Needless to say, i seriously began to be worried about it.

I felt much better when i found out shortly afterwards that the data hadn't vanished at all, they were right there. It was just the application that was displaying nothing.
But why on earth it's displaying nothing if the data are right there?

Well, i'll investigate tomorrow i thought.

Then tomorrow arrived and i started an endless mail exchange with John at Shellprompt.net where my Oracle Application Express based sites are hosted.

I started examining the Oracle Apex active session log and soon it became clear to me i had a problem with the so-called application level items.
There were a couple of those global variables that were not initialized and, to make it worse, this was happening erratically.
Sometimes the values were there, sometimes they were not.

To make the story short, we logged in and out dozens of times, for six straight hours, without making any progress, every solution we tried was failing in the end.

Until John saw the light.

The problem was in the conditional process running after the page submit.

Items were initialized after that the user submitted the page by pressing the login button. Or at least that was my understanding of the user's behaviour.

The password field in the login form is not a simple text field.
It carries an additional property, the automatic submit in case the user presses the enter key.


And in this case there is going to be no login button event ever.

No button, no event, no process, no initialization.
It was sufficient to remove the conditional clause based on the login button event from the application items initialization process definition and the nightmare was finally over.

This story tells me how long it can take to fix a problem if you do not focus early on every tiny detail of the puzzle, including how the user interacts with the programs. Moreover if you are a user too, your understanding of the problem is heavily biased by your personal experience: i am using the mouse most of the time, while others are using the keyboard to do the same operation.

And now just let me thank John once more for his invaluable and continuous support.