Cannot have execute_query in post-change but can have it when-radio-changed

Question

why is it possible to put execute_query in a when-radio-changed trigger but one cannot put it in
a post-change or post-text-item trigger? (11.1.1.4)
For example I want to ask for a year, and a month. I don't much feel like creating radio items for all those years. Whenever a year
or a month is changed I want it to reconstruct the where clause and execute the query. But the year not being a radio group
is more problematic about how to get execute_query to run. What is thinking here? I think that a text item post-change deserves as much power as a radio_group change! It's unfair.

Answer 1

Over the years, I have found that the people that complain about Oracle Forms the most are the people that refuse to learn how Oracle Forms works. You can't expect to develop in a any framework unless you learn the rules of the framework. I've seen numerous complaints about the lack of documentation on Forms and yet the single most important form of documentation is the Oracle Forms Help system. The answer to virtually every question you might have can be found in the Forms help system, but it helps to understand a little about how Forms functions so you can ask the right questions in the help system.
I also find it hard to understand how an employer will throw someone, with little or no exposure to Oracle Forms, into a Forms project and expect them to "Pick it up" along the way rather than take the time and expense to send them to an Oracle Forms class. How can the employer expect the employee to be successful if they are unwilling to give them the resources they need to be successful. If you are one of the unfortunates that are in this situation, then you could at least perform a simple Google search on "Forms Tutorials" and you will find numerous on-line "Free" tutorials. Don't worry about the Forms version used by these tutorials as you are only going through the tutorial to learn how to create a Form and how the Forms tool interacts with the database; which is doesn't matter which Forms version you are using because this part hasn't changed all that much between the Forms versions.
There are even some really good books (however, quite old) that you can purchase that teach you all the basics of Oracle Forms. Here are just a few:
Developing Oracle Forms Applications by Albert Lulushi
Oracle Forms Developer's Handbook by Albert Lulushi
Oracle Developer: Advanced Forms and Reports by Peter Koletske
Programming with Oracle Developer by Matthew BennettThese are just a few books and yes they are all for older versions of Oracle Forms. But the concepts you will learn apply to any Forms version.
While I admit that it is inconvenient that I can't call a Restricted built-in from certain triggers once you understand the reasons why you can't call Restricted built-ins it make sense why Oracle built their event model the way they did. By calling certain restricted built-ins in a trigger, such as the When-Validate-Item trigger, you could very easily cause an an endless loop to occur in your application. For example, if you were allowed to call the GO_BLOCK or GO_ITEM built-ins from a When-Validate-Item trigger you could cause cascading validation events to occur. While this is not a bad thing in and of itself, but what would happen if I sent the Forms Navigation cursor to go to an item before I had completed my validation logic. The item I sent the cursor too also happens to have validation logic assigned to it that just so happens to send the navigation cursor to the item I just left. Understand, the first item has not yet completed it's validation process and the second item sends the cursor right back the first item - which triggers a new validation event on the first item. Now I've got compounding events in the execution stack and I've put my application into a loop that I will never get out of because I've got validation logic that never completes successfully so the validation event never exits - it just keeps running and running.
At first, you might say that it is the developers responsibility to ensure this does not happen and the developer should be more careful with their code to prevent this from happening and you would be right. We (developers) are responsible for writing safe code. However, after a while, software manufacturers eventually put restrictions in place because there are enough irresponsible developers out there causing problems and the only way to fix the issue is through the use of framework restrictions.
Having said that, Oracle Forms has certain restrictions for good reasons. Because you don't understand what those reasons are is not a good reason to complain about the restrictions. Rather, I would hope, that your lack of understanding of a particular framework/methodology would encourage you discover the "Why's" and "How come's" of the framework.
The simple fact of the matter is you cannot be successful with Oracle Forms unless you learn how to program within the Forms Framework. You can't take C++, Java or any other programming language and apply the rules of programming these languages to Forms. You absolutely must learn how Oracle Forms operates and what the rules are for developing successful Forms applications.
That's my two cents on the topic. I'm trying to start a flame war; I'm just tired of hearing people complain about Forms just because they don't understand or haven't taken the time to understand how Forms operations and what the rules are for developing within Oracle Forms.
Sincerely,
Craig...
Edited by: CraigB on Aug 2, 2011 12:38 PM