Microsoft® .NET Compact Framework (Core Reference)

Author A. Wigley, S. Wheelwright, R. Burbidge, R. MacLeod, M. Sutton Pages 896 Disk N/A Level All Levels Published 01/22/2003 ISBN 9780735617254 Price $59.99 To see this book's discounted price, select a reseller below.	More Information About the Book Table of Contents Sample Chapter Index Companion Content Related Series About the Author Support: Book & CD Rate this book

Chapter 4: Building Windows Forms Applications

• Working with Forms
• Setting Properties of the Form Class
• Keeping to Form Display Guidelines
• Creating Custom Dialog Boxes
• Using Built-In Dialog Boxes
• Working with the InputPanel Control
• Using the MainMenu Control
• Using the ToolBar Control
• Programming Form Activation and Deactivation on Pocket PC
• Programming Activate and Deactivate
• Programming Form Close
• Closing of Applications by the Pocket PC Shell
• Handling the Tap-and-Hold Event
• Handling Pocket PC Hardware Keys
• Giving an Application Its Final Touches
• Associating an Icon with Your Application
• Adding a Shortcut to the Start Menu
• General Design Guidelines
• Summary

4   Building Windows Forms Applications

This means that when you design an application that targets the Pocket PC platform or any Windows CE device with limited screen size, you should plan the number, size, and layout of the controls for each form.

An example application, DVD Catalog, will be used throughout this chapter to illustrate the points that are being made. The full DVD Catalog application is available with this book's sample files.

Working with Forms

Setting Properties of the Form Class

• The FormBorderStyle property   controls the style of the border of the form. This property can be set at design time using the Microsoft Visual Studio Properties window or at run time using code. The settings that can be used for this property are the same in both Windows CE and Pocket PC projects, although the results are different in a Windows CE and a Pocket PC project. The default setting for a form is FormBorderStyle.FixedSingle.

In a Pocket PC project, setting the property to FormBorderStyle.None creates a form with no border and no caption. The form can be moved and resized using code. Setting the property to any other value will cause the form to expand to fill the desktop area and will prevent the form from being moved or resized. The desktop area is the entire screen minus the Start menu bar and the main menu bar of the application, if present.

In a Windows CE project, setting the property to FormBorderStyle.None or FormBorderStyle.FixedDialog creates a form with no border or caption. The form can be resized and moved using code but not by the user. All other settings create a form with a border and a caption that can be moved using code or by the user, but the form can be resized only using code.

• The WindowState property   accepts two settings only: FormWindowState.Normal or FormWindowState.Maximized. No setting to minimize a window exists for this property.

In a Pocket PC project, the form will fill the desktop area when its WindowState property is set to FormWindowState.Normal. Setting the property to FormWindowState.Maximized will make the form fill the entire screen, obscuring the Start menu bar while still displaying the form's main menu if one is present.

In a Windows CE project, setting the WindowState property to FormWindowState.Normal will cause the form to display according to the Size property. Setting the form to FormWindowState.Maximized will cause the form to expand to fill the entire desktop area.

• The ControlBox property   can be set to true to display the form's control box or false to prevent the form's control box from displaying. In a Pocket PC form, the control box contains only one button: a close button or a minimize button. The MinimizeBox property controls which button is displayed. In a Windows CE form, the control box always contains a close button, and the minimize and maximize buttons are displayed depending on the settings of the MinimizeBox and MaximizeBox properties of the form.
• The MinimizeBox property controls the display of the minimize button. In a Pocket PC form, the MinimizeBox property can be set to true to display the minimize button, which looks like an X on the Pocket PC, or it can be set to false to display a close button, which looks like an OK button on the Pocket PC. In a Windows CE form, the MinimizeBox property can be set to true to display the minimize button or it can be set to false to hide the minimize button.
• The MaximizeBox property controls the display of the maximize button. In a Pocket PC form, this property has no effect; forms have no maximize button on Pocket PC devices. In a Windows CE form, the MaximizeBox property can be set to true to display the maximize button or it can be set to false to hide the maximize button.
• The Size property is used to set the form's width and height. In a Pocket PC form, this property is used only if the FormBorderStyle property is set to FormBorderStyle.None. In a Windows CE form, the Size property sets the height and width of the form just as it does in a full .NET Framework form.
• The Location property specifies the placement of the form on the screen, using x and y coordinates relative to the upper left of the screen. In a Pocket PC form, the Location property has no effect unless the form's FormBorderStyle property is set to FormBorderStyle.None. In a Windows CE form, the Location property sets the position of the form on the screen just as it does in a full .NET Framework form.

Keeping to Form Display Guidelines

Creating Custom Dialog Boxes

AddDVDForm addForm = new AddDVDForm();

if (addForm.ShowDialog() == DialogResult.OK)
{
    // Add DVD to summary Table
}

If you need to, you can use the FormBorderStyle and Size properties of the Form class to size a dialog box so that it's smaller than the screen size of the device. If you size a dialog box like that, you should also use the Location property to place your dialog box in the most convenient position on the screen. One possible use for a dialog box form that is smaller than the screen size is to present a Logon dialog box on top of the main form the first time the application is launched.

A common task for an application that uses sensitive data is to require the user to log on before the data is accessed. It's important to make sure that an application that contains sensitive data is secure. For more information about securing your application, see Chapter 12.

The problem with having a logon screen, rather than a logon dialog box, appear first in your application is that the logon screen will function as the main form of the application. This might not seem like a problem, until you close the form to free resources. Because the form is your application's main form, closing it will close your application. The solution is to have your main form call a logon form as a dialog box and continue or exit depending on the result of the dialog box.

The DVD Catalog example application uses a logon dialog box to protect the user's DVD data. The application has a form called MainForm, as shown in Figure 4-1, which lists the DVDs in the user's collection.

Click to view graphic

Figure 4-1   DVD Catalog application: MainForm.

The application uses another form, called LogonForm, to request the user's logon details. Figure 4-2 shows what LogonForm looks like.

Click to view graphic

Figure 4-2   DVD Catalog application: LogonForm.

The following code is the Load event handler for MainForm. In this event handler, we need to create a new instance of the LogonForm object and call it as a dialog box. The logon form will return DialogResult.Ok or DialogResult.Cancel, depending on whether the user entered a valid user name or simply closed the logon form. If the user's details are valid, the main form will continue with its normal processing. If the user closes the logon form without entering a valid user name the main form will close the application.

private void MainForm_Load(object sender, System.EventArgs e)
{
    LogonForm LogonFrm = new LogonForm();

    if (LogonFrm.ShowDialog() == DialogResult.Cancel)
    {
        LogonFrm.Dispose();
        this.Close();
    }
    else
    {
        this.Text+= " - " + LogonFrm.Username.Text;
        LogonFrm.Dispose();
        OpenCatalogFile(DataFile);
    }
}

The Click event handler for the Logon button of LogonForm, shown in the following example code, checks the user's logon credentials, using the CheckUser routine defined elsewhere in the application. The event handler returns a dialog box result of DialogResult.OK if the user enters a valid user name.

private void LogonButton_Click(object sender, System.EventArgs e)
{
    if (CheckUser(Username.Text))
    {
        this.DialogResult = DialogResult.OK;
    }
    else
    {
        MessageBox.Show("Username not valid. Please Try Again", 
            "Logon Error");
    }
}

If the user closes the form without entering a valid user name, the logon form's CancelButton_Click event handler returns DialogResult.Cancel to the main form, which will then close the application.

private void CancelButton_Click(object sender, System.EventArgs e)
{
    this.DialogResult = DialogResult.Cancel;
}

Using Built-In Dialog Boxes

Both of these classes have a Filter property, which allows you to specify which file types will be displayed in the file list of the dialog box. Like custom dialog boxes, built-in dialog boxes return a DialogResult value to specify whether the results of the dialog box were successful.

The following code sample shows the use of the OpenFileDialog class, and Figure 4-3 shows the code running in a Pocket PC environment:

OpenFileDialog openDialog = new OpenFileDialog();
openDialog.Filter = "XML Files|*.xml";

if (openDialog.ShowDialog() == DialogResult.OK)
{
    OpenCatalogFile(openDialog.FileName);
}

Click to view graphic

Figure 4-3   The OpenFileDialog class in action on a Pocket PC device.

The following code sample shows the use of the SaveFileDialog class, and Figure 4-4 shows the code running in a Pocket PC environment:

SaveFileDialog saveDialog = new SaveFileDialog();
saveDialog.Filter = "XML Files|*.xml";

if(saveDialog.ShowDialog() == DialogResult.OK)
{
    SaveCatalogFile(saveDialog.FileName);
}

Click to view graphic

Figure 4-4  The SaveFileDialog class in action on a Pocket PC device.

Working with the InputPanel Control

When the InputPanel control is available for use by the user, it is important to design the form so that the InputPanel control obscures no important controls when it is raised. This is especially true for controls that require text input. The two techniques to use in designing your forms are to have all the text-input controls above the top of the raised InputPanel control and to move controls on the form to make room for the InputPanel control. Remember to include scroll bars on the form if you opt for the second technique. This will allow the user to keep the InputPanel control raised and still have complete access to all the controls on your form.

The code below demonstrates how to show the InputPanel control when a TextBox control receives the focus and hide the InputPanel control when the TextBox control loses the focus:

private void textBox1_GotFocus(object sender, System.EventArgs e)
{
    // When the user selects this field, automatically raise SIP
    inputPanel1.Enabled = true;
}

private void textBox1_LostFocus(object sender, System.EventArgs e)
{
    // Automatically lower SIP
    inputPanel1.Enabled = false;
}

As has already been stated, it is important to be mindful of the use of the InputPanel control by the user when designing your forms. Remember to place any text-input controls above where the InputPanel control will be displayed or to move controls up when the InputPanel control is displayed.

The EnabledChanged event is triggered when the InputPanel control is raised or lowered by the user or programmatically. Text-input controls that will be obscured when the InputPanel control is raised should be placed inside a Panel control. When the InputPanel is raised, you can reposition the Panel control at the top of the screen.

The following code shows the EnabledChanged event handler moving a Panel control above the InputPanel control when the InputPanel control is raised, and moving it to the back to its original position when the InputPanel control is lowered.

private void inputPanel1_EnabledChanged(object sender, System.EventArgs e)
{
    // Trap whenever the InputPanel is raised or lowered
    // whether by user action or programmatic control

    // The Bounds property returns the size and location of
    // Input Panel.
    // Set the top of the Panel that is inside the Form to
    // -1 * the height of the input panel to ensure SIP
    // never obscures controls
    if (inputPanel1.Enabled == true)
        this.panel1.Top = 180 - inputPanel1.Bounds.Height;
    else
        this.panel1.Top = 180;

}

Figure 4-4 in the previous section shows the InputPanel control with the on-screen keyboard selected.

Using the MainMenu Control

To add menu items to the MainMenu control, click the menu bar and type in the menu items your application requires. Figure 4-5 shows the MainMenu control in Windows Forms Designer.

Click to view graphic

Figure 4-5   MainMenu control in Windows Forms Designer.

Figure 4-6 shows the menu expanded showing the New, Open, and Save commands that have been added to the MainMenu control of the DVD Catalog sample application.

Click to view graphic

Figure 4-6   The MainMenu control as it appears in a Pocket PC application.

You can create a cascading menu structure with the MainMenu control, but a cascading menu should be used on a Pocket PC application only when it will not clutter the screen. A Windows CE application can be less conservative in the use of its menus because a Windows CE device generally has a larger screen and a more Windows-like appearance.

The MainMenu control of a Pocket PC application should include functions that are necessary for the use of the application but not functions that will be used frequently by the user. You should place frequently used functions on a toolbar to allow the user easier access to them.

Functions should not be duplicated between the main menu and a toolbar. This is different from the recommendation for desktop applications, where you should provide the user with several different approaches to accessing any of the application's functions. With a Pocket PC application, you need to be aware of the limited space available to your application and place access to the application's functions in the most appropriate location. Do not hide a function in a menu when the function is likely to be used every time your application is run.

Using the ToolBar Control

As is the case with the MainMenu control, when a toolbar is added to a form, the SIP control is available to the user, so you should take care to design your forms with the SIP in mind.

The toolbar acts as a container for buttons that the user can click to perform functions in your application. Each button can have a different image assigned to it from an ImageList control to help identify the button's function. The default image size is 16 by 16 pixels, but the image size can be changed to suit the images you want to use. Image size guidelines are provided in the section "General Design Guidelines" later in this chapter. The style of each button can be set to DropDownButton, PushButton, ToggleButton, or Separator. The DropDownButton style causes the button to display a pop-up menu when clicked. The PushButton and ToggleButton styles cause the buttons to look like standard buttons, but the ToggleButton style causes the button to stay down when clicked. The Separator style displays a space or a line between buttons, allowing clearer definition between button groups.

When you have added a ToolBar control to your form, you add buttons to the ToolBar control using the ToolBar Button Collection Editor. With the ToolBar Button Collection Editor, you can define the type of buttons that appear on your ToolBar control by setting ToolBar button properties such as Style, DropDownMenu, and ImageIndex. The ImageIndex property accepts an index into the list of images in the ImageList control associated with the ToolBar control. Figure 4-7 shows the ToolBar Button Collection Editor for the ToolBar control in the DVD Catalog sample application.

Click to view graphic

Figure 4-7   ToolBar Button Collection Editor.

The following code shows an example of adding a ToolBar control to a form programmatically:

    // Create ImageList object for use by the toolbar
    ImageList imageList = new ImageList();

    // Load bitmaps into ImageList from the application's embedded resource
    Bitmap bmp;
    bmp = new Bitmap(
        Assembly.GetExecutingAssembly().
            GetManifestResourceStream(
                "NETCFDevelopersReference.Add.bmp"));
    imageList.Images.Add(bmp);

    bmp = new Bitmap(
        Assembly.GetExecutingAssembly().
            GetManifestResourceStream(
                "NETCFDevelopersReference.Edit.bmp"));
    imageList.Images.Add(bmp);

    bmp = new Bitmap(
        Assembly.GetExecutingAssembly().
            GetManifestResourceStream(
                "NETCFDevelopersReference.Delete.bmp"));
    imageList.Images.Add(bmp);

    // Associate ImageList object with the toolbar
    DVDToolbar.ImageList = imageList;

    // Add the New button to the Toolbar
    ToolBarButton btn = new ToolBarButton();
    btn.ImageIndex = 0;
    DVDToolbar.Buttons.Add(btn);
            
    // Add the Edit button to the Toolbar
    btn = new ToolBarButton();
    btn.ImageIndex = 1;
    DVDToolbar.Buttons.Add(btn);
    DVDToolbar.Buttons[1].Enabled = false;
    DVDToolbar.Buttons[1].Visible = false;
            
    // Add the Delete button to the Toolbar
    btn = new ToolBarButton();
    btn.ImageIndex = 2;
    DVDToolbar.Buttons.Add(btn);
    DVDToolbar.Buttons[2].Enabled = false;
    DVDToolbar.Buttons[2].Visible = false;

    // Add toolbar to form
    this.Controls.Add(DVDToolbar);

    // Add the event-handler delegate.
    DVDToolbar.ButtonClick += new ToolBarButtonClickEventHandler(
        this.DVDToolbar_ButtonClick);

The preceding code first creates an ImageList object and then loads three bitmaps using the GetManifestResourceStream function to retrieve the images from the embedded resources of the application. The toolbar will use these bitmap images to display the three buttons that will be added to the ToolBar control.

Then the code sets a reference to the ImageList object in the ToolBar control. Three ToolBarButton objects are created, made to reference an image in the ImageList object, and then added to the ToolBar control.

The ToolBar control is then added to the current form. Finally an event-handling routine is associated with the ButtonClick event of the ToolBar control. This allows you to detect when the user taps a button in the toolbar and to take whatever action is required for the tapped button. An example of an event handler for the toolbar's ButtonClick event, from the DVD Catalog example application, is shown here:

protected void DVDToolbar_ButtonClick(object sender,
    ToolBarButtonClickEventArgs e)
{    
    // Evaluate the Button property to determine which button was clicked.
    switch(DVDToolbar.Buttons.IndexOf(e.Button))
    {
        case 0: // Add
            MessageBox.Show("Add DVD Button clicked");
            break; 
        case 1: // Edit
            MessageBox.Show("Edit DVD Button clicked");
            break; 
        case 2: // Delete
            MessageBox.Show("Delete DVD Button clicked");
            break; 
    }
}

This code example displays a message specifying which button was clicked. The button that was clicked is identified by inspecting the ToolBarButtonClickEventArgs parameter, which includes a reference to the button that was clicked. The IndexOf method of the Buttons collection in the toolbar returns the zero-based index of the button, which is numbered from the left side of the toolbar. Note that if you have used separator buttons in the toolbar, the number of functioning buttons will not be consecutive. Figure 4-8 shows how the toolbar should look. It shows the three buttons—Add, Edit, and Delete—in the finished application.

Click to view graphic

Figure 4-8   DVD Catalog toolbar example.

Programming Form Activation and Deactivation on Pocket PC

The second significant recommendation for an application on a Pocket PC is that once started the user should not be able to close it. When a user switches to another application, the window for the new application fills the screen and hides your application in the background; it is deactivated. When the user selects your application again from the Start menu or by clicking the application's icon on the Most Recently Used (MRU) bar on the Today page, your application is activated once more.

Programming Activate and Deactivate

When an application is deactivated, the .NET Compact Framework automatically performs a garbage-collection process to release memory resources that the application no longer needs. Garbage collection in the .NET Compact Framework has been optimized for the lower memory specification of the device rather than for speed and scalability, as in the full .NET Framework. All memory allocations are taken from a single pool so that it's easy to free up memory resources if the device starts to run low on memory.

You will still need to specifically release resources such as open database connections, large objects in memory (such as datasets), and connections to COM ports. Two Form events are provided by the .NET Compact Framework to enable you to detect when your application is moved to the background or restored to the foreground of the system display windows. The Form.Deactivate event is used to detect when your application is minimized, and the Form.Activate event is used to detect when your application is brought back to the foreground of the system. The following code example shows event handlers in C# for both of these events:

private void Form1_Activate(object sender, System.EventArgs e)
{
    // Put code here to restore any database or COM port connections etc.
}

private void Form1_Activate(object sender, System.EventArgs e)
{
    // Put code here to free up application resources
    // (i.e. Database or COM port connections etc.)
}

Programming Form Close

In a Pocket PC form, set the MinimizeBox property to true to display the minimize button (the X icon) or set the property to false to display a close button (the OK icon). The main form of your application should not be closeable. All dialog box forms that your application displays should be full screen and should be closeable through the OK icon to return to your main application form.

Closing of Applications by the Pocket PC Shell

If resources on the device become low, the operating system will start to close applications that are running in the background. Because your application might be closed by the operating system while it is minimized, it is important that the application write any changes to data immediately or in response to the Deactivate event. If the application doesn't write data changes immediately or during the Deactivate event, there is a risk of leaving the data in an inconsistent state.

Handling the Tap-and-Hold Event

If you want to provide functionality other than a context-sensitive menu to the tap-and-hold action on a control, you must trap the action manually. You should create a timer control on your form and set its interval to the amount of time you want the user to hold the stylus for before triggering your function. Capture the MouseDown event to start the timer and the MouseUp event to stop the timer. Capture the timer's Tick event to execute the code for the tap-and-hold action. You should also capture the MouseMove event if you want to allow the user to move the control without triggering the tap-and-hold action. The following code shows the technique just described to provide a custom tap-and-hold event for Form1:

private void timer1_Tick(object sender, System.EventArgs e)
{
    // Your action code should go here
}

private void Form1_MouseDown(object sender,
    System.Windows.Forms.MouseEventArgs e)
{
    // Start Timer control
    timer1.Enabled = true;
}

private void Form1_MouseUp(object sender,
    System.Windows.Forms.MouseEventArgs e)
{
    timer1.Enabled = false;
}

Handling Pocket PC Hardware Keys

Click to view graphic

Figure 4-9   Pocket PC device hardware keys.

It is possible to capture these keys in the KeyDown event that occurs when the user presses these keys.

The Compaq iPAQ has a central pad that generates the following five different types of key codes:

• Keys.Up is triggered when the top of the pad is pressed.
• Keys.Down is triggered when the bottom of the pad is pressed.
• Keys.Left is triggered when the left side of the pad is pressed.
• Keys.Right is triggered when the right side of the pad is pressed.

• Keys.Return is triggered when the center of the pad is pressed.

The following code example shows a KeyDown event handler. The code uses the KeyCode of KeyEventArgs to detect which key has been pressed.

private void Form1_KeyDown(object sender, 
    System.Windows.Forms.KeyEventArgs e)
{
    switch (e.KeyCode)
    {
        case Keys.Up:
            MessageBox.Show("UP key pressed");
            break;
        case Keys.Down:
            MessageBox.Show("DOWN key pressed");
            break;
        case Keys.Left:
            MessageBox.Show("LEFT key pressed");
            break;
        case Keys.Right:
            MessageBox.Show("RIGHT key pressed");
            break;
        case Keys.Return:
            MessageBox.Show("key pressed in");
            break;
    }
}

Giving an Application Its Final Touches

Associating an Icon with Your Application

Click to view graphic

Figure 4-10   Project Property Pages dialog box.

Adding a Shortcut to the Start Menu

The configuration file used to build your application's CAB file is used to define the shortcut that will be created for your application when it's installed on the device. If you use Visual Studio .NET to create your application's CAB file, a shortcut section will be included in the configuration file. The following section describes which sections of the configuration file need to be changed to create a shortcut for your application if you build the configuration file manually.

Three sections of the configuration file are affected. The first section that you need to change is the DefaultInstall section. You use the CEShortcuts keyword to point to the section that will create the shortcuts for your application. The following code is an example of the DefaultInstall section from the configuration file of the DVD Catalog application:

[DefaultInstall]
CopyFiles = Files.Common
CEShortcuts = Shortcuts

After pointing to the section that will define your shortcuts, you add that section into the configuration file. The format of the entries in this section are shortcut_filename, shortcut_type_flag, and target_file.

• shortcut_filename is the name of the shortcut. It will appear in the Start Menu.
• shortcut_type_flag defines whether the shortcut is to a file or a folder. Empty or 0 represents a shortcut to a file; a non-zero numeric value represents a shortcut to a folder.
• target_file specifies the target file or folder of the shortcut.

The following listing shows the Shortcuts section of the configuration file of the DVD Catalog application:

[Shortcuts]
DVD Catalog, 0, DVDCatalog.exe

The third and final section that you will change is the DestinationDirs section. This section defines the paths to use for various other sections. You enter the shortcut's section name followed by the path to your shortcuts. The following listing below is taken from the configuration file for the DVD Catalog application:

[DestinationDirs]
Shortcuts = 0, %CE17%
Files.Common=0,%InstallDir%
Files.ARM=0,%InstallDir%
Files.SH3=0,%InstallDir%
Files.MIPS=0,%InstallDir%
Files.X86=0,%InstallDir%

This topic will be covered in more detail in Chapter 6.

General Design Guidelines

On a Pocket PC device, there is no keyboard, so all text input needs to be done using the SIP. If you compare the use of the SIP and a keyboard, you will find that the SIP is time-consuming and error-prone. When you design your input forms, reduce the need to enter textual information by providing drop-down lists of the most common entries for each input. For example, the Task Input Form on a Pocket PC device uses drop-down list boxes to provide the user with the most common subjects for the task. Figure 4-11 shows the Task Input Form with the Subject drop-down list box displayed.

Click to view graphic

Figure 4-11   Task Input Form showing the Subject drop-down list box.

Remember that the user is using a stylus instead of a mouse to select items on your form. To aid the user in selecting items, make controls sufficiently large to avoid target misses. The recommended size for a button on a Pocket PC device is 5 millimeters (21 by 21 pixels) for a stylus target and 9 millimeters (38 by 38 pixels) for a finger target. Also provide sufficient space between controls to reduce the risk of a missed hit. This is particularly important if the commands perform cut or copy functions.

As a general rule, you should consider the way the user is going to use your application. Minimize the distance between common controls and tasks so that the user is not constantly moving the stylus back and forth across the screen.

Consider the way the device is held. The most frequently used or most important information should be positioned so that it's not obscured by the user's hands when he or she is entering data or selecting items.

Group related controls together for ease of access. You should reduce the movement the user needs to make to perform the most common functions of your application.

On a Pocket PC device, the screen's height is greater than its width. This is different from the standard desktop screen, which has a width greater than its height. You must be aware of this narrower display when you design your application's forms. Controls should be arranged vertically rather than horizontally to avoid making the user scroll the display horizontally to see all the controls. Forms should be designed to fit all the required controls onto one form without scrolling. This allows the user to see all the information that he or she requires without having to scroll the display. If a form can't be designed to display all the required controls without scrolling, the most important controls should be displayed first and secondary controls should be displayed in the area of the form that will need to be scrolled into view. Avoid overlapping forms and controls, especially in a Pocket PC application.

Feedback to the user should be provided for the actions he or she performs. This feedback can be in the form of a sound or a change in the appearance of the form or controls. The use of graphics to enhance your applications is covered in Chapter 21.

Summary

Last Updated: January 4, 2003

Top of Page