Graphics Reference
In-Depth Information
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.
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.