Activity blocks are used to define particular instances of a service that can "do something". Activities - or services - are created by adding them to the programming canvas. Activity blocks that do not have any input connections create activities (services) when the programme is started.

It is possible for the activity/service represented by a block to appear several times within the same programme. That is, it is possible to create several instances of the same activity within the same programme.

It is also possible to create several different versions of the same activity/service.

For example, we might have a robot with several touch sensors. The program code might require us to respond to one particular touch sensor in several ways - for example, if it is pressed or released - requiring us to write several different programme fragments relating to the same touch sensor within our programme. In this case, we would need several different instances of the same activity/service.

In addition, we might want to define different behaviours depending on whether a touch sensor on the front of the robot is activated, or whether a separate touch sensor on the back of the robot detects a collision., In this case, we would need to use activity blocks that represent different instances of different touch sensor activities/services.

When you add an activity block to a programme that already uses an activity block of the same type, you will be prompted as to whether or not you want to use another instance of the activity already used within the programme (another reference to a touch sensor you have already used, for example) or whether you want to add an instance of a new service (add a reference to a new touch sensor altogether, for example).

The Microsoft VPL Introduction page describes Activity Blocks as follows:

 

Activity blocks typically include the activity’s name and borders that represent its connection points. An activity block may also include graphics to illustrate the purpose of the activity as well as user interface elements that may enable the user to enter values, assignments, or transformations for data used in an activity.

Activities are connected through their connection pins. A connection pin on the left side of an activity represents connection point for incoming/input messages and a pin on the right represents its connection point for outgoing/output messages.

 

An activity receives messages containing data through its input connection pins. An activity’s input pins are connection points to its predefined internal functions known as actions or handlers (which can be either as functions provided by a service or nested data-flows).

 

An activity block activates and processes the incoming message data as soon it receives a valid incoming message. All data sent to the activity is consumed by the activity. For data to be forwarded on through the activity’s output, the receiving activity must replicate the data and put it on its output connection.

 

An activity may have multiple input connection pins and each with its own set of output connection pins. Output connection pins can be one of two kinds: a ''result output or ''notification output (sometimes also referred to as a event or publication output). Result outputs are displayed as rectangular connection pins while publication outputs have round connection pins.

 

 

A response output pin is used in situations where an outgoing message (data) is sent as the result of an specific incoming action message. Notification pins can send information resulting from an incoming message, but more typically fire a message as the a change their internal state. They can also generate messages multiple times, whereas a result pin only sends out a single message on the receipt of an incoming message. So notification output pins are used for sending message data without having to repeatedly request or poll for the state of an activity.

One aspect that can be confusing about the VPL at first is that the same Activity block may appear to offer you different options at different times. This is because the blocks are context sensitive. That is, the range of connections you can choose from when wiring up the block depend on what you are wiring it to, and whether it is already wired to something else (and if so, exactly what it is already wired to).

Take the Timer Activity block, for example. Here, I am wiring from a Timer block to an if/condition block. The From connections are the notification messages that the Time block can output. The To Condition is the input argument the If block can accept.

The Timer block can raise many more response messages than it can notifications. Again, the To connections correspond to allowable inputs to an If/condition activity block (not shown).

In the following example, let's see what happens if we wire from one Timer activity block (not shown) to another Timer block (depicted). The first Timer passes a particular message to the second one. The second, depicted Timer reads the received message type as the type defined by the selected To: connection.

What sort of message is passed to the second Timer depends on which output - response or notification - we are wiring to on the first block.

If we wire from a response output on the first timer, rather than the notification output, the choice of "From:" messages we can receive changes in a corresponding way.

Note that the order in which you wire up the blocks (input first or output first) may limit the options you have on the other connection, or even disable the other connection altogether.

For example, if I wire the notification output of a Timer to another block using the TimerComplete notification output, the input connection disappears. What has happened is that the block has been configured to look out for 'other' instances of itself that have raised an event stating that the timer has completed a timed event. When the Timer 'notices' that another instance of itself has completed a timer action, it creates the "Time's up" string and passes it to the TextToSpeech activity. So can you work out what the following programme does?

It should start a timer, say "Started" and then, 3 seconds later (that is, 3000 milliseconds later) it should say "Time's Up".

Not that the Timer blocks are both separate instances of the same Timer (I created the second one by copying the first one). The two TextToSpeech activities are both separate instances of the same object - again, I created the second one by simply copying the first and pasting it back to the programme canvas.

You can see that both Timer blocks are separate instances of the same Timer, by clicking on one of them and changing its name in the properties window (then hit 'Return'). You'll notice that the name of the other Timer changes too - because it is, in fact, the same Timer.

To help you keep track of whether one block is an instance of another block in your programme, or an instance of a completely separate object, you might find it useful to change the name of an activity block whenever you add it to the canvas.