Scripting Solutions with WSH and COM
In "Scripting Solutions with WSH and COM: Extending WSH with ActiveX Controls," July 2002, InstantDoc ID 25288, I introduced you to GooeyScript, an ActiveX control built to extend Windows Script Host (WSH) that lets you quickly create event-driven forms. Let's look at how we can use some of the other great ideas in GooeyScript, such as incorporating multiple buttons, custom backgrounds, progress bars, and various other form elements.
Closing Forms Gracefully
The BasicWorkingForm.vbs script in my July column demonstrated how you can create a simple form with one button. The script displays the form on screen, pauses execution until you click the button, and finishes execution after you click the button. The script included one problem that I didn't have time to address. The form's border contains a close button. When you click the close button, the form disappears and GooeyScript terminates the object instance and the script. Lee Carlson, the author of GooeyScript, has addressed this problem by adding a special event called FormClose that redisplays the form and prevents GooeyScript from terminating the script prematurely.
Listing 1 shows NewBasicWorkingForm.vbs, which adds a new snippet of code to BasicWorkingForm.vbs. The new code snippet, which callout A in Listing 1 shows, is easy to understand: You simply handle the Form::FormClose event in the same way you handle any other event, use the Form::OnTop property to place the form on top of all other windows, and use the Form::Visible property to make the form visible. Of course, if you want to use the close button to close the form gracefully, you must modify the contents of gsForm.FormClose() to do whatever you want to do, then use gsForm.Unload to close the form gracefully.
Creating Multiple GooeyScript Buttons
If we pick up where we left off last time, the next logical step is to expand the single-button form into a multibutton form. After you understand this approach, you can apply the same principles to your own scripts.
Listing 2 shows Multi-ButtonForm.vbs, which uses the script in Listing 1 as a base. To add three additional buttons to the form, you must modify the original line of code that created the Exit the form button to create four new buttons. These buttons will appear on screen as Button 1 through Button 4 and are denoted as Button1 through Button4, respectively, in the script. You load the four buttons to the form by using the Button::Load method. To equally space the buttons on the form, position Button1 100 pixels from the left edge of the form and 50 pixels down from the top, position Button2 350 pixels from the left edge and 50 pixels down from the top, position Button3 100 pixels from the left edge and 150 pixels down from the top, and position Button4 350 pixels from the left edge and 150 pixels down from the top.
If you didn't modify anything else in the script and you clicked any of the buttons, the script would generate an event for the gsForm_ButtonClick event to handle. The event handler would call the Form::UnPause method, close the form, and terminate the script gracefully. However, you typically want each button to trigger a separate action. Because you have only one event-handler subprocedure for all four buttons, you must place all the code that needs to occur for each button action into the event-handler subprocedure. However, unless the code for all the buttons is short, you would typically use a Select Case statement to call a separate subprocedure for each button.
Notice that the Select Case statement at callout A in Listing 2 selects on only three buttons, just to demonstrate that you can create a button that does nothing. If you click a button and nothing happens, remember that you might have forgotten to handle the event in the event handler or you might be calling an empty subprocedure.
Button 1 in this example does nothing, no matter how many times you click it. To show that Button 1 does nothing, Button2 calls the HideButton1 subprocedure, which uses the Button::Visible method to hide Button 1. As a result, when you click Button 2, the script hides Button 1 on the form.
Button3 looks innocuous, calling the SayHi3 subprocedure, which creates a separate message box. However, I discovered a pitfall while playing with GooeyScript. If you use the Form::OnTop method at the beginning of a script to make the form always appear on top of all other windows, you can't use MsgBox or WScript::Echo to display a message on screen: Because the main form is always on top, you can't click the message box that Button 3 generates. To acknowledge the message box, you need to select it from the taskbar or move the form. Alternatively, after you click Button 3 for the first time, subsequent clicks will bring the message box to the front because the script doesn't call the Form::OnTop method between button clicks. A better way to let the user acknowledge the message box is to set the OnTop requirement to FALSE, display the data you need, then reset the form to be on top, assuming that's what you want to do.
Button 4 calls the CloseMyForm subprocedure. When you click this button, the script uses the Form::UnPause method to terminate the script gracefully.