More Tour.
As you can see in the earlier snippets, the tour script has stages and actions. There's also a "default stage" named with an asterisk, where you can put default event handlers (such as the client example: wherever you are in the tour, this will trigger when the event matches). If you specify parameters on the <t:Action> element, that action will only triggers when the parameters match; a regular-expression parser makes parameter matching quite flexible.

Events happen from all sorts of things. At the workstation, client-type events are raised: navigation, space members arriving, chat, a timer (which you can stop and restart), windows opening and closing, by instant messages arriving or being sent, roles changing, and a few others. The bot watches all the tools in the space and triggers events appropriately (documents being added, deleted, modified; and so on). The script can also trigger custom events. Then each user (workstation and bot) shares their events across the network, so effectively the event model is seamlessly location-independent. There's a latency in the network, of course; that's sometimes quite important (as we'll see later on).

In the raw application, stage names are not coordinated between actors. The tour implements a "stage follower", though, since coding gets a lot easier if you can track stages automatically by default; the code looks like this:

	<t:Action Trigger="PropertyChanged" Param1="CurrentStageUser">

		if( tour.DoesStageExist( Param2 ) )

			tour.GoTo( Param2 );

	</t:Action>

<t:Stage Name="*">

	<t:Action Trigger="WindowOpen" Param1="Add Recipients">

		tour.PushBookmark();

		tour.GoTo( "HandleRecipientsDialog" );

	</t:Action>

</t:Stage>


<t:Stage Name="HandleRecipientsDialog">

	<t:Action Trigger="Timer" Param1="2">

		ui.Bubble( "This is how you find Groove contacts." );

	</t:Action>

	<t:Action Trigger="WindowClose" Param1="Add Recipients">

		tour.GoTo( tour.PopBookmark() );

	</t:Action>

</t:Stage>