This content has been marked as final. Show 4 replies
This is typical functionality for the Message() built-in. If there is a current message displayed in the Status Bar and a new message is displayed, the current message is automatically promoted to the "Default Alert". It is a good habit to always call Clear_Message() before calling Message() to ensure you don't unintentionally promote a message to the Default Alert. For this reason, all of the places I've worked we have had a PL/SQL Library procedure for displaying messages and alerts. This ensured there were no "Unitentional" promoted messages and gave us a standard method for displaying Messages and Alert.
Thanks for your response. I didn't know about the clear_message function, so that's interesting.
This is a migration where we wanted to do as little as possible to get a Forms 4.5 system running in 11g.
The display in the default alert would be ok for us, if it didn't look like an error message - many of these are informational messages. Is it possible to configure what this default alert looks like?
Is it possible to configure what this default alert looks like?Unfortunately, no - you can't change the way the default Alert looks. The assumption being, if a message makes to the default Alert, then it is "Unhandled" and should be displayed as an error. That is my interpretation at least. ;)
The least impact way to handle this would be to add the CLEAR_MESSAGE built-in before each MESSAGE call; although, this is still a lot of work it allows to you eliminate this issue with the least amount of work. You could also, just add CLEAR_MESSAGE to those forms that are giving you trouble.
The best way to handle this would be to implement a messaging package that wraps all of the Oracle Messaging related built-in's in to a simple and easy way to display messages. This is also the most work, but gives you the greatest flexibility and standardizes they way you display messages in your Forms App. It would require you to create a messaging package and place it in a PL/SQL Library and then attach library to all of your forms (unless you have an existing library you can use).
If you take this route, I would also recommend creating a standard "ON-ERROR" trigger that is subclassed to all of your forms so you standardize how Errors are displayed as well.
Unfortunately, both options are probably not what you wanted to hear. :(
Thanks for your thoughts Craig.
It's interesting to see an issue that is not a problem for one client is something that seemingly makes a system completely unusable for another set of users.
I think that judicious use of clear_message at a few key points might be enough.
When you are migrating a system of 200 complex forms, the less you have to do the better :)