If you're going to use a JavaScript var to change which page it is submitted to, then leave out the -action and somewhere in your JavaScript function checkForm()you probably need a line like

document.FormName.action = page_to_be_submitted_to;

And now we're into the world of JavaScript which I don't even pretend to understand. Best of Luck.

First, thanks for the nudge in the right direction. I still don't have it quite right; . . .something about the state of the browser with regard to JavaScript vs. Perl executing on the server thing, I guess.

BTW, I've Googled around for info. on application menu systems, etc. Seems like a lot of sophisticated stuff out there. My approach is to dynamically load a drop-down (pop-up?) scrolling window from an applications table maintained in a MySQL database. -- Make a selection, and execute the associated executable object. Problem solved.

As I mentioned, a state problem apparently requires a second click on the Execute Application (i.e., Submit) button. First pass, the same Applications Menu panel is displayed. Second click, the requested application is executed. Interesting, too, that if you go back to the menu, select another ap., the thing returns to the previous ap. after which you can return to the menu, click submit, yet again, on the next ap., and the next ap. will be executed.

I haven't dwelled on the solution, but FYI, here is a sample of code that almost works. Notice that the -action argument is omitted; therefore, defaults(?) to the current document):

Using the CGI to start the form:

print   header(),
        start_html(-title=>$title, -bgcolor=>"cyan"),
        checkForm(),
        $cgi->start_form(
                -name=>"apps_menu",
                -method=>"GET",
                -onsubmit=>"return checkForm( this )"
);
[download]

. . .and a little farther down, notice that the "-onclick=>set_apx()" apparently is not recognized by the popup_menu()function (subroutine, . . .whatever); however; executing immediately after the call produces the somewhat desirable results. I did try placing the call to set_apx() inside the checkForm() routine that is called -onsubmit, but that did not work: :

# ------------------------------
# Display Application Menu.
# ------------------------------
print
qq(<tr><td width=\"175\" align=\"right\">
          <b>Application: </b></td><td>),
$cgi-> popup_menu
(
        -name=>'ap_name',
        -values=>\@ap_names,
        -labels=>\%ap_labels,
        -size=>'8',
#       -onclick=>set_apx()   Not good!
);

set_apx(); # Sort-of works here as planned.
[download]

. . .and finally finish up the main with the usual suspects. It's probably worth noting that regarding the design, the execute button could be eliminated and the desired application could be immediately executed "-onclick" from the popup menu (if possible, . . .should be?), because the user can only select one item from the list:

print br(),
submit(-name=>"action", -value=>"Start Application"),
reset,
end_form(),
end_html();
$dbh->disconnect();
exit(0);
[download]

. . .and here is the "Set Application to Exec." subroutine that generates the JavaScript:URL that overrides the -action argument of the form tag generated by CGI.pm:

# ----------------------------------------------------
sub set_apx { # Generate some JavaScript here:
        print qq(<script><!--
                document.apps_menu.action=apps_menu['ap_name'].value;
        // --></script>);
}
[download]

This event-sensitive, client-side JavaScript is obviously executing the desired application, but like an old diesel tractor, . . .you have to double-clutch it.

Suggestions?

Thanks,
Ron W.