Although this design is perfectly reasonable, it doesn??™t save you any work. Many application
tasks can be triggered through a variety of routes, so you??™ll often need to code several
event handlers that call the same application method. This in itself isn??™t much of a problem
(because the switchboard code is so simple), but life becomes much more complicated when
you need to deal with UI state.
A simple example shows the problem. Imagine you have a program that includes an
application method named PrintDocument(). This method can be triggered in four ways:
through a main menu (by choosing File ??° Print), through a context menu (by right-clicking
somewhere and choosing Print), through a keyboard shortcut (Ctrl+P), and through a toolbar
button. At certain points in your application??™s lifetime, you need to temporarily disable the
PrintDocument() task. That means you need to disable the two menu commands and the
toolbar button so they can??™t be clicked, and you need to ignore the Ctrl+P shortcut. Writing the
code that does this (and adding the code that enables these controls later) is messy. Even
worse, if it??™s not done properly, you might wind up with different blocks of state code overlapping
incorrectly, causing a control to be switched on even when it shouldn??™t be available.
Pages:
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533