Anyone who has a suggestion or a recommendation I would appreciate

it. I have a form that has numerous GOTFOCUS & LOSTFOCUS events that

include some extensive scripts. It seemed fairly easy to debug all

of these scripts as I developed the form with the scripts in the

GOT/LOST FOCUS events. Now I'm wondering if it would be easier to

maintain forms with numerous event scripts by placing all this code

in one(1) stored procedure and use a CASE statement to handle the calls. All I would have in each event script would be a call to the

SP.

TIA

Steve C.

In my oppinion, definitely the stored procedure with a CASE statement.

There are two major advantages to it:

- Code visibility - everything is in one place, and by looking at the CASE statement you can tell which controls have what event defined.

- Ability to re-compile "on-the fly". You can keep the stored procedure open, run your form, and then keep making changes to the code without having to close the form to change the code.

I use the following subroutine definition:

compile subroutine XXX( CtrlEntId , CASE_SWITCH , param1 , param2, param3, param4)

Another very good way would be:

compile subroutine XXX( CASE_SWITCH, CtrlEntId , param1, param2, param3, param4)

In this case you can choose to skip passing CtrlEntId if you want at certain times.

param 1 through 4 are the extra parameters that the events get passed in ( like CreateParam, Flag, etc.) .

Hope this helps

Dave Pociu

We now always use a stored procedure with the same name as the window and have a quick event which passes a branch and @Self where appropriate. As Dave P says, Subroutine WindowName(Branch, CtrlEntId, Param1, Param2, Param3).

Now that we can pass @Window, @Self, @Param1 etc etc from quick events this is the easiest.

[email protected]

Sprezzatura Ltd

World Leaders in all things RevSoft

When do you want to reboot today?[/b] </QUOTE> —- === At 06 AUG 1998 07:40PM Don Bakke wrote: === <QUOTE>Taking the very good suggestions so far just a little bit further, we create a promoted GOTFOCUS event that calls a stored procedure. So you still get the benefits of on-the-fly compilation and the ability to debug without having to define a GOTFOCUS event for every control. [email protected] SRP Computer Solutions </QUOTE> —- === At 07 AUG 1998 10:23AM Steve C. wrote: === <QUOTE>Don, How do you create a promoted GOTFOCUS event? Steve C. </QUOTE> —- === At 07 AUG 1998 12:25PM Don Bakke wrote: === <QUOTE>Steve, So I know how detailed to get, do you know how to create promoted events of any kind? Do you get Sprezzatura's Electronic Newsletters (if so, they have an excellent article a few issues back on this stuff.)? [email protected] SRP Computer Solutions </QUOTE> —- === At 07 AUG 1998 01:04PM Steve C. wrote: === <QUOTE>Don, Nope, I do not know how to create promoted events of any kind? Let me look at Sprezzatura's Electronic Newsletters first and if I have any addditional questions I'll get back to you. Thanks… Steve C. </QUOTE> View this thread on the forum...