Datasheet

Chapter 1: Workfl ow Programming Principles
17
As Listing 1 - 6 shows, the CompositeActivity activity exposes a Boolean property named
CanModifyActivities. As the name suggests, you must set this property to true before you can add child
activities to the Activities collection property of the composite activity or before you can modify any
child activity in the Activities collection property. Note that this property is marked as protected. This
means that only the subclasses of the CompositeActivity class can set this property, and consequently
only the subclasses of the CompositeActivity class can add child activities to its Activities collection
property or modify child activities in this collection.
To put it differently, only a composite activity itself is allowed to add child activities to its own Activities
collection property or to modify its own child activities. No outsider is allowed to add child activities to
it or modify any of its child activities. This puts a composite activity in complete control of its child
activities. This is very similar to C# composite program statements. For example, it would not make
sense for the code outside of a C# { } composite program statement to add new program statements to
this composite program statement or to modify any of its child program statements. You ’ ll see numerous
examples of custom composite activities throughout this book.
Developing Custom Flow Control Activities
As discussed earlier, workflows as logical programs, just like C# programs, need control flow program
statements such as “ if, ” “ while, ” “ for, ” “ { }, ” and so on. Just as you cannot write a useful C# program
without using these control flow program statements, you cannot implement useful workflows without
using logical “ if, ” “ while, ” “ for, ” “ { }, ” and other control flow program statements.
One big difference between WF as a logical workflow programming language and a standard procedural
programming language such as C# is that the set of control flow program statements in WF is extensible.
This means that you can implement your own custom control flow program statements and use them in
your workflows just like standard control flow contructs that ship with WF. This section provides several
examples to help you gain the skills you need to implement your own custom flow control activities.
A traditional procedural programming language such as C# comes with two types of flow control
constructs: iterative and non - iterative . Thus, “ for ” and “ while ” are examples of iterative flow
control constructs whereby the flow control program statement repeatedly executes its child program
statement, which is a { } program statement. Conversely, “ if, ” “ else if, ” “ { }, ” and “ else ” are examples of
non - iterative flow control constructs whereby the flow control program statement executes its child
program statements once in the prescribed order.
Developing Non - Iterative Flow Control Constructs
This section explains how to implement non - iterative flow control constructs that execute their child
program statements once in the prescribed order.
c01.indd 17c01.indd 17 8/25/08 4:02:56 PM8/25/08 4:02:56 PM