Graphics Reference
In-Depth Information
4.5 Interaction
We already discussed how button clicks and slider-value changes are handled in
the test bed (and in WPF in general): A Click or ValueChanged method is called.
Keyboard interaction is a little different. Key presses that happen anywhere in
the main Window are handled in two stages: First, some of them are recognized as
commands (like “Alt-X” for “Exit the program”); second, those not recognized as
commands are handled by a method called KeyDownHandler , which responds to
all key presses by either ignoring them (for presses on modifier keys like Control
or Shift) or displaying a small dialog box indicating which key was pressed. As
you write more complex programs, you may want to adapt this part of the code to
do particular things when certain keys are pressed.
Finally, the actions taken when menu items are selected get defined in the
InitializeCommands method. For many commands (like Application.Close ,
indicating that the application should close a window), there's already a prede-
fined way to handle them and a predefined key press associated with the com-
mand. For these, one can simply write things like CommandBindings.Add(new
CommandBinding(ApplicationCommands.Close, CloseApp)) ; where CloseApp
is a small procedure that pops up a dialog to confirm that the user does, in fact,
want to close the application. For others, slightly more complex mechanisms must
be invoked. As we do not expect you to add any new commands, we leave it to
you to decide whether to examine the mechanism for doing so.
4.6 An Application of the Test Bed
Let's now return to the corner-cutting example we discussed at the beginning of
the chapter. To create an application that demonstrates this, we'll need to remove
most of the code in Window1.cs and start with a simple polygon created by the
user. We'll describe the interaction sequence and then write the code.
The GraphPaper starts out empty; there are two buttons, labeled “Clear” and
“Subdivide”. When the user clicks on the graph paper a polygon P 1 appears, with
vertices at the clicked locations (after two clicks, the polygon consists of two iden-
tical line segments; after three, a triangle; etc). When the user clicks the Subdivide
button, a subdivided version, P 2, of the first polygon appears; subsequent clicks
on Subdivide replace P 1 with P 2, and P 2 with a subdivided version of P 2, etc. so
that a polygon and its subdivision are always both shown. A click on the Clear but-
ton clears the graph paper. Once the user has subdivided the polygon, we disable
further clicks on the graph paper; you might want such clicks to add new points
to the subdivided polygon, but it's not clear where, in the subdivided polygon, the
new points ought to be added, and so we simply avoid the issue.
With that description in mind, let's write the code. 7 We'll need an
isSubdivided flag (initially false ) to tell us whether the user has subdivided the
polygon or not. The Clear button should reset this, as well as clearing the graph
paper. And if there are no points in the polygon yet, Subdivide should have no
effect.
We start from a copy of the test bed code, and modify the XAML to remove
the slider and to change the text on the buttons:
7. The entire program is available on the topic's website for download.
 
 
 
Search WWH ::




Custom Search