重拾VB6（22）：Mouse Pointer, Keyboard Events, Interrupting Background Processing

来自MSDN-2001-OCT: Visual Tools and Languages/Visual Studio 6.0 Documentation/Visual Basic Documentation/Using Visual Basic/Programmer’s Guide/Part 2: What Can You Do With Visual Basic/Responding to Mouse and Keyboard Events/

1. Customizing the Mouse Pointer

(1)You can use the MousePointer and MouseIcon properties to display a custom icon, cursor, or any one of a variety of predefined mouse pointers.

(2)With the MousePointer property you can select any one of sixteen predefined pointers.

When you set the MousePointer property for a control, the pointer appears when the mouse is over the corresponding control. When you set the MousePointer property for a form, the selected pointer appears both when the mouse is over blank areas of the form and when the mouse is over controls with the MousePointer property set to 0-Default.

(3)To use a custom icon or cursor, you set both the MousePointer and MouseIcon properties.

a) Select a form or control and set the MousePointer property to 99-Custom.

b) Load an .ico file into the MouseIcon property. For example, for a form:

Form1.MouseIcon = LoadPicture("c:/Program _
Files/Microsoft Visual _
Basic/Icons/Computer/Disk04.ico")

(4)Cursors are .cur files and, like icons, are essentially bitmaps. 

Cursors also contain hot spot information. The hot spot is a pixel which tracks the location of the cursor — the x and y coordinates. Typically, the hot spot is located at the center of the cursor. Icons, when loaded into Visual Basic through the MouseIcon property, are converted to the cursor format and the hot spot is set to the center pixel.

The two differ in that the hot spot location of a .cur file can be changed, whereas that of an .ico file cannot.

Cursor files can be edited in Image Editor, which is available in the Windows SDK.

Visual Basic does not support animated cursor (.ani) files.

2. Responding to Keyboard Events

(1) The KeyPress, KeyUp, and KeyDown events

(2) Only the object that has the focus can receive a keyboard event.

A form has the focus only if it is active and no control on that form has the focus. This happens only on blank forms and forms on which all controls have been disabled. However, if you set the KeyPreview property on a form to True, the form receives all keyboard events for every control on the form before the control recognizes them.

(3) The KeyDown and KeyUp events provide the lowest level of keyboard response. Use these events to detect a condition that the KeyPress event is unable to detect.

Before using the KeyUp and KeyDown events, make sure that the KeyPress event isn't sufficient. This event detects keys that correspond to all the standard ASCII characters: letters, digits, and punctuation on a standard keyboard, as well as the ENTER, TAB, and BACKSPACE keys. It's generally easier to write code for the KeyPress event.

You also should consider using shortcut and access keys. You can assign shortcut keys without writing additional code.

(4) Note that some controls (command buttons, option buttons, and check boxes) do not receive arrow-key events: Instead, arrow keys cause movement to another control.

3. Key codes

(1)

Private Sub Text1_KeyPress (KeyAscii As Integer)
   KeyAscii = Asc(UCase(Chr(KeyAscii)))
End Sub

(2) When the user types uppercase "A," the KeyDown event gets the ASCII code for "A." The KeyDown event gets the same code when the user types lowercase "a." To determine whether the character pressed is uppercase or lowercase, these events use the shift argument. In contrast, the KeyPress event treats the uppercase and lowercase forms of a letter as two separate ASCII characters.

(3) Key codes for letter keys are the same as the ASCII codes of the uppercase character of the letter. So the keycode for both "A" and "a" is the value returned by Asc("A").

4. Writing Form-Level Keyboard Handlers

(1) If you have defined a shortcut key for a menu control, the Click event for that menu control occurs automatically when the user types that key, and no key event occurs.

(2) Similarly, if there is a command button on the form with the Default property set to True, the ENTER key causes the Click event for that command button to occur instead of a key event. If there is a command button with the Cancel property set to True, the ESC key causes the Click event for that command button to occur instead of a key event.

(3) Notice that the TAB key moves the focus from control to control and does not cause a key event unless every control on the form is disabled or has TabStop set to False.

(4) When the KeyPreview property of the form is set to True, the form recognizes the keyboard events before the controls, but the events still occur for the controls. To prevent this, you can set the keyascii or keycode arguments in the form key-event procedures to 0.

Private Sub Form_KeyPress (KeyAscii As Integer)
Dim NextTabIndex As Integer, i As Integer
   If KeyAscii = 13 Then
      If Screen.ActiveControl.TabIndex = _
      Count - 1 Then
         NextTabIndex = 0
      Else
         NextTabIndex = Screen.ActiveControl._
         TabIndex + 1
      End If
      For i = 0 To Count - 1
         If Me.Controls(i).TabIndex = _
         NextTabIndex Then
            Me.Controls(i).SetFocus
            Exit For
         End If
      Next i
      KeyAscii = 0
   End If
End Sub

5. Interrupting Background Processing 

(1) Windows is a preemptively multitasking operating system, which means that idle processor time is efficiently shared among background tasks. Priority is always given to the application that the user is working with, however. This ensures that the mouse and keyboard always respond immediately.

During long background tasks, your application cannot respond to user input. Therefore, you should provide the user with a way to interrupt or cancel the background processing by writing code for either the mouse or keyboard events.

(2) One way to allow users to interrupt a task is to display a Cancel button and allow its Click event to be processed. You can do this by placing the code for your background task in a timer event, using the following guidelines.

• a) Use static variables for information that must persist between occurrences of the Timer event procedure.
• b) When the Timer event gets control, allow it to run slightly longer than the time you specified for the Interval property. This ensures that your background task will use every bit of processor time the system can give it. The next Timer event will simply wait in the message queue until the last one is done.
• c) Use a fairly large value — five to ten seconds — for the timer's Interval property, as this makes for more efficient processing. Preemptive multitasking prevents other applications from being blocked, and users are generally tolerant of a slight delay in canceling a long task.
• d) Use the Enabled property of the Timer as a flag to prevent the background task from being initiated when it is already running.

(3) Although Timer events are the best tool for background processing, particularly for very long tasks, the DoEvents function provides a convenient way to allow a task to be canceled.

DoEvents switches control to the operating-environment kernel. Control returns to your application as soon as all other applications in the environment have had a chance to respond to pending events. This doesn't cause the current application to give up the focus, but it does enable background events to be processed.

You may want to prevent an event procedure that gives up control with DoEvents from being called again before DoEvents returns. Otherwise, the procedure might end up being called endlessly, until system resources are exhausted. You can prevent this from happening either by temporarily disabling the control or by setting a static "flag" variable, as in the earlier example.

(4) Avoiding DoEvents When Using Global Data