Home » Developer & Programmer » Forms » Getting around the restricted built-ins
Getting around the restricted built-ins [message #336096] Thu, 24 July 2008 15:22 Go to next message
OracleUser12345
Messages: 5
Registered: July 2008
Junior Member
Hello all,

I am working on a 6i Form that used to have a field with a 'Post-Text-Item' trigger. The user liked the feature of this trigger because any way that she left the field (via tab, mouse leave, enter, etc), that trigger would fire. She especially liked mouse leave (clicking out of the field). Originally, this form was written so bad that it required a very large overhaul. They did not write it on a record-by-record level and did it on a field-by-field level, meaning there was no need for restricted functions like next_record, go_block, and go_item. When I changed it to a record-by-record level, I had to change the type of trigger being used on that field, a 'Key-Next-Item' trigger. This way I can use functions like next_record, previous_record, etc. Unfortunately, the functionality of leaving the field via mouse does not fire the trigger (only tab and enter do). The user would like to get that functionality back. I am having troubles with this because of the restricted built-ins. Is there a way around this? I have tried triggers like, 'Post-Change', 'When-Mouse-Leave', 'Post-Text-Item', When-Validate-Item', 'When-New-Item-Instance', etc. None of these triggers accomplish what I (or the user) want, either because the trigger cannot use restricted built-ins or it does not work when you "click out" of the field. Does anyone have any thoughts on how to get around these restricted built-ins? Thanks in advance.

OracleUser12345
Re: Getting around the restricted built-ins [message #336131 is a reply to message #336096] Thu, 24 July 2008 23:57 Go to previous messageGo to next message
gurupatham
Messages: 66
Registered: March 2008
Location: Chennai
Member
You cannot control the action while moving from one item to others by using Go_Item or Go_Block.
Instead of Using post-text-item trigger , you can write all your functionality like go_item ,go_block ,etc in when-new-item-instance of that same block level.

it may be accomplish your task.
Re: Getting around the restricted built-ins [message #336298 is a reply to message #336096] Fri, 25 July 2008 09:54 Go to previous messageGo to next message
OracleUser12345
Messages: 5
Registered: July 2008
Junior Member
Thank you for responding to my post. Unfortunately, the 'When-New-Item-Instance' trigger will not work because I do not stop to accept input when navigating the form. This trigger would work great if it didn't have that restriction.

http://www.oracle.com/webapps/online-help/forms/10g?topic=whennwit_html

"When-New-Item-Instance Trigger Restrictions

The conditions for firing this trigger are not met under the following circumstances:

* Oracle Forms navigates through an item, without stopping to accept input"
Re: Getting around the restricted built-ins [message #336303 is a reply to message #336096] Fri, 25 July 2008 10:20 Go to previous messageGo to next message
OracleUser12345
Messages: 5
Registered: July 2008
Junior Member
I just wanted to clarify that when I said 'field-by-field' level, I meant 'item-by-item' level. And, I am currently using the 'Key-Next-Item' trigger, not the 'Post-Text-Item'.
Re: Getting around the restricted built-ins [message #336657 is a reply to message #336096] Mon, 28 July 2008 09:45 Go to previous messageGo to next message
OracleUser12345
Messages: 5
Registered: July 2008
Junior Member
Does anyone else have suggestions?
Re: Getting around the restricted built-ins [message #336820 is a reply to message #336657] Tue, 29 July 2008 02:29 Go to previous messageGo to next message
wency
Messages: 450
Registered: April 2006
Location: Philippines
Senior Member

you can using timer.
http://www.orafaq.com/forum/t/91070/0/
Re: Getting around the restricted built-ins [message #336970 is a reply to message #336096] Tue, 29 July 2008 08:26 Go to previous messageGo to next message
OracleUser12345
Messages: 5
Registered: July 2008
Junior Member
I don't see how a timer helps my specific situation. Can you explain more?
Re: Getting around the restricted built-ins [message #337071 is a reply to message #336970] Tue, 29 July 2008 19:11 Go to previous messageGo to next message
wency
Messages: 450
Registered: April 2006
Location: Philippines
Senior Member

I can't really understand your query, your title is getting around with restricted triggers, but seems like you want to use those triggers.
Be specific. What do you want? What triggers you want to fire? When do you want those triggers to fire?
Re: Getting around the restricted built-ins [message #337084 is a reply to message #336096] Tue, 29 July 2008 21:15 Go to previous messageGo to next message
Kevin Meade
Messages: 2098
Registered: December 1999
Location: Connecticut USA
Senior Member
there is no easy answer for this one. I would have two thoughts:

1) if the original form (that needed a massive overhaul) did not have this problem, then maybe it was not so poorly written after all. Might be they solved this problem using the techniques they did (or not, maybe it was just a bad form).

2) in my experience with forms (and I wrote a lot of it in my day), I remember the following guidelines

a) less is more. The less forms code you have to write, the better your form will be. With that in mind, techniques that mininmized the need for code are usually the best approach. Usually this means doing most of the work in the database. Things like views and instead of triggers are huge to simplifying a form.

b) any time you want a specific functionality in forms, there are two ways to do it; the forms way, and your way. LOV is a great example. Many people don't use LOVs because they are not a standard windows widget. Instead they do stuff like write C routines and do callouts to get the functionality they want. OK, go head, but not me. It is always better code wise, to do things how forms wants them and simply accept the "less liked" alternative that it is. I have seen projects where 90% of the time spend was spent in avoiding a natural forms feature in favor of something home grown because somebody from a "human factors" group said it had to be so. Human factors are important but like anything you have to keep reality in mind.

c) the last thing to remember, is that sometimes to get forms to do what you want, you nave to lie to it. Sneaky tricks can be way useful. One I remember was this:

the on-error trigger is a non-restricted event. You can raise an error any time you want, even in code executing in restricted mode. Thus, you can at atny time raise a forms exception. this will stop processing and jump to the on-error trigger. This trigger, executing in non-restricted mode, will let you do whatever you want.

I never had much cause to use this trick so don't call me, I'll call you.

Good luck, Kevin
Re: Getting around the restricted built-ins [message #435764 is a reply to message #337084] Thu, 17 December 2009 17:02 Go to previous messageGo to next message
salrizzo
Messages: 7
Registered: December 2009
Junior Member
I'm afraid the On-Error trigger only allows unrestricted built-ins
Re: Getting around the restricted built-ins [message #435783 is a reply to message #336096] Thu, 17 December 2009 23:59 Go to previous message
Kevin Meade
Messages: 2098
Registered: December 1999
Location: Connecticut USA
Senior Member
Thus we see an example of how forms behavior changes over time. There was a time when this was possible. Indeed I have a book on my shelf detailing the technique in reference to using list of values. But this is an old technique; a form 3.0/form 4.5 hack.

Current documentation clearly says on-error cannot execute restricted built-ins (I checked).

Thanks for the update. Kevin
Previous Topic: How to create new Folder in run time
Next Topic: Multiple Block Navigation Problem
Goto Forum:
  


Current Time: Sat Oct 01 14:27:44 CDT 2016

Total time taken to generate the page: 0.24410 seconds