Redirecting Form "Save" Button URL Based on Insert or Change Action

[Rob Mikkelsen]

I have a form that is used to identify an item.  When the form is saved, it moves to another form that allows the user to add descriptors to that item from a predetermined set based on the item identified (kind of a wizard approach).  Form to form works great!  However, if the user changes the item, I would like to return to the browse where I have the existing descriptors and pictures available for editing.

Is it possible to redirect the form save button on a change request vs an insert request?  If so, how?

I don't see any embed points in the code after the GenerateForm routine that allow me to change it after it is defined and before it is used.  Of course, I am still on NT 4.30 so this may already have been addressed.

Thanks!

Rob

[Bruce]

Hi Rob,

There are 2 answers here - which are two different approaches, and are unrelated to each other.

1. You're thinking about it backwards. The URL for the Save button is set when the form is generated. So you can't make a decision "after they press save". What you can do is make a decision _inside_ the target. So, for example;

Form A calls NetWebPage B when Save is pressed. NetWebPage B decides at that point which form to include. It doesn't "redirect" to the form, it just _includes_ the form. However you need to be careful with this approach because it's easy to use a Value when a session value is required.

2. Since the Save is calling a "chained" form, simply allow the form to include _all_ the possible fields you want. You can group the fields onto tabs. Then using the SessionValues set by the Form A, you can decide which _tab_ of B to display. This way you don't need to decide _which_ form to display, you just need to decide which tab to display on the form. This has the benefit of keeping all the form fields together, and you end up with fewer procedures in your app.

I recommend the second approach.

Cheers
Bruce

Cheers
Bruce

[Rob Mikkelsen]

Bruce,

I am not thinking about it backwards, just sideways.

I need to change the address of the "Save" button before the form is generated.  The information I have available to make that decision is the action requested which is passed as a value to the procedure.  Therefore, the decision could be made by the first form procedure BEFORE it is generated.  Instead of the Save URL being "form2" it could be set prior to form generation to "browse1."

When I execute the child procedure which takes me to the descriptor form, saving the data takes approximately 15 seconds which I could avoid if I simply avoided that form in the first place.  In many cases this form has approximately 60 different parameters that can be changed.  Since I only save the ones with actual selections, I have to delete the old data first, then save the new.

If I can speed up the save process I could force the user through both forms and simply remove the choice to edit the second form from the child browse.

It seems simpler to send the user back to the browse! <g>

[kevin plummer]

Have you tried using a local variable as the URL and then just setting this via p_web.SSV?

I use this lots to bring lookup screens (and other stuff) back to the right form without replicating the same lookup for every data entry screen that needs it.

[Rob Mikkelsen]

Of course!  That should do the trick.  I guess I haven't loaded that into my bag of tricks yet. 

I will give that a shot in the morning and let you know how it goes.

Thanks, Kevin!

Rob

[Rob Mikkelsen]

I used the template code to set a session variable "Loc:Destination" with the browse routine name on change, and the form routine name on "insert."  I then set Loc:Destination as the URL on Save.  I had to load the session variable just prior to form generation, but the effect was exactly what I wanted.  Now I have a wizard routine for an insert and an edit feature for each portion of the data.  Works great!

Thanks for the pointer, Kevin!

Rob