GEEK I have a problem using a submit function in the IHTMLFormElement interface. The HTML page I am controlling has multiple submit buttons. After calling the submit method, the server script doesn't properly recognize which button has been pressed. GEEK The solution for this is quite simple. The <input type="submit"> element can have both a name and a value that can be used to distinguish it, thus allowing multiple submit buttons on a single form, or allowing multiple forms to submit to the same backend processing. Figure 1 shows two ways to do this. GEEK How can I pass an array of objects to a VBScript-based ASP application? I can do it easily when I'm using a Visual Basic®-based program, but I can't get it to work with VBScript. GEEK If I'm reading between the lines correctly here, you're probably using a Visual Basic program to pass the array to the other program. In that case, no, you can't pass an array of objects in this fashion. An Active Server Page (ASP) is invoked via HTTP. Through the invocation mechanism you can pass in parameters, but not objects. If the caller could somehow enumerate the object information as a series of values, it could be passed into the Web page by building up the appropriate URL and invoking it (like http://web.server/page.asp?value1=blah&value2=blah). GEEK How do you pass a value from one HIDDEN-type input to another on an HTML page without using an HTML form? If I have a line like this in an ASP script

<INPUT TYPE=HIDDEN NAME="BNAME" VALUE=<% = TRIM(RSCat("BNAME")) %>>

I want to take the value of the BNAME button and pass it from one page to another like this:

<INPUT TYPE=HIDDEN NAME="BNAMEX" VALUE=<% = Request("BNAME") %>>

GEEK You're going about this in a slightly incorrect fashion. For an <input type="hidden"> value to be passed to another page, it either has to be part of a <FORM>, or you have to physically force its use as part of the URL reference.     For the following code to work, the URL used to navigate to this page needs to include "?BNAME=value":

<input type="hidden" name="BNAMEX" value=<%= request("BNAME") %> >

As you know, the easiest way to do this is through the use of a <FORM> on the previous page, but this isn't the only way to move a value across pages.     Since you are already building the originating page using ASP, it would be more straightforward to insert this value into the link used to get to the second page, instead of including it as an <input type="hidden"> value. So on your originating page, you would use code such as:

<a href="http://privateserver/secondpage.asp?BNAME=<%=TRIM(RSCat("BNAME"))%>"> click here</a>

If you can make assumptions about the scripting capabilities of the client used to view the page, there's another way to do this. Instead of making a simple URL link, you could make a click on the link activate the submit method of a hidden form. GEEK Do you know of any mechanism that can provide a mutex code block/critical section in an ASP script? I have a critical piece of code that will be writing files to the server's disk and don't want multiple users to hit it at the same time. The code is currently written in VBScript. GEEK The Lock and Unlock methods of the Application object should be able to meet your needs. This allows you to lock access to the Application object associated with your site, preventing any other user currently browsing the site from modifying its values. This is often used to illustrate adding a hit counter to a page:

<% Application.Lock Application("NumVisits") = Application("NumVisits") +1 Application.Unlock %>

Here, the lock/unlock prevents two users from simultaneously updating the NumVisits counter.     It sounds like you might need a slightly more robust usage, something more along the lines of:

<% haveAccess = false Application.Lock if Application ("bUnlocked") then Application ("bUnlocked") = false haveAccess = true end if Application.Unlock %>

Here you use Lock and Unlock to protect the testing (and perhaps setting) of the bUnlocked variable. Upon exit from this test, the local haveAccess variable indicates whether you own the mutex. You then perform the appropriate manipulations, being sure to reset the bUnlocked state back to true once you have finished with your critical processing. GEEK In your February 1997 column, you responded to an inquiry on the availability of redir.dll by saying a stripped- down version was being prepared for people to use. Is there any news on this yet? GEEK As it turns out, making redir.dll available for redistribution was rendered unnecessary by the increasing popularity of ASP, a special form of HTML that includes scripting commands that are executed on the server before the page is sent back to the user.     In a follow-up column I presented the following ASP code that essentially duplicates the functionality of redir.dll.

<% url = Request.QueryString("url") if (left(url, 1) = "/") then host = Request.ServerVariables("http_host") if (len(host) > 0) then url = "http://" & host & url else url = "http://" & Request.ServerVariables("server_name") & url end if end if Response.Redirect(url) %>

Between <% and %> is the script code that will be executed by the server. Here is the HTML code that you might use to interface with this:

<form action="http://www.yoursite.com/redir.asp"> <select name="url"> <option value="/default.html">My Home Page <option value="http://www.microsoft.com">Microsoft </select> <input type="submit" value="go!"> </form>

One of the primary benefits of something like this is that the code is easily modified without having to have a full C programming environment and distribution method. If the previous code doesn't quite do what you want it to do on your site, you can easily customize its behavior. A released version of redir.dll might not have suited your needs. GEEK I'm running Microsoft® Internet Explorer 4.0 in kiosk mode, and would like to provide a button on an HTML page that will close Internet Explorer 4.0 completely when clicked. Is this possible? GEEK This can be done simply by adding the following code to your page:

<input type=button value="Close" onclick="window.close()">

When you try this, you'll notice that it will bring up a dialog box telling the user that the current page is attempting to close down the active browser window. This is a security feature and cannot be avoided.     However, if the window was opened by the current domain, then it can be closed without this warning. Here is some sample code to illustrate this:

<html> <body> <input type=button value="window.open" onclick="window.open('WindowCloser.html', 'kiosk', 'fullscreen=yes')"> <input type=button value="window.close" onclick="window.close()"> </body> </html>

Run this code and click on the window.close button. You'll get the warning dialog. Choose not to allow the window to be closed down. Now click on the window.open button. This will open a new instance of the browser in kiosk mode. Then click on the window.close button, which will close down the browser without warning. GEEK In Visual InterDev™ I have a simple page with two comboboxes, an edit field, and a Save button. I'm using DTC server components for all of these controls. The first combobox, Projects, is bound to a DTC Recordset control. The second combobox, Vendors, is populated in the Projects combobox's OnChange event and also in the Projects combobox's bound Recordset control's DataComplete event, with all the Vendors available for a given project. The textbox value needs to be written to a table when the user presses the Save button.     In Visual Basic, all you need to do is load both comboboxes and press the Save button to write the textbox value. Whenever I click on a new item in the Projects or Vendors combobox, the page reloads and resets all the values. If I click on the Save button, the page reloads and I lose all my values. Why? GEEK Most likely, your DTCs are set for server-side execution of the query and results. This means that any time a change occurs in one control, it has to force a client/server round-trip to request the new values, and for greatest compatibility this is done as a full server refresh of the page you are viewing currently.     If you can make sure that Internet Explorer 4.0 is being used as the browser, then you can turn on client-side rendering via Dynamic HTML and ADO or RDS. To do this, select Document in the control's Properties window, then start up the Custom dialog. In this dialog you will see a place to set the scripting platform to either Client or Server. Set it to Client, then apply this change. There will still be a client/server round-trip invoked, but it will be happening in the background via ADO or RDS, so the page won't redraw.

From the May 1999 issue of Microsoft Internet Developer.