| Getting around the restricted built-ins [message #336096] |
Thu, 24 July 2008 15:22  |
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  |
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 #337084 is a reply to message #336096] |
Tue, 29 July 2008 21:15 |
 |
Kevin Meade
Messages: 2103
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 #435783 is a reply to message #336096] |
Thu, 17 December 2009 23:59 |
|
Kevin Meade
Messages: 2103
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
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
