Hopefully, you have noticed, that a WorkItem is activated while one of its SmartParts respectively controls is entered?
It is independent to which of the WorkItem's collections (Item- or SmartPartCollection)  the control was added, it only has to be derived from System.Windows.Forms.Control.
This works due to the ControlActivationService of the CompositeUI.Winforms Library. If the control is entered the ControlActivationService activates the containing WorkItem. The SimpleWorkItemActivationService ensures that only one WorkItem is active.
Paulo Morgado shows us how to replace the SimpleWorkItemActivationService by an hierarchical ActivationService.

 

ManagedObjectCollections are used in CAB to manage the EventTopics-, Items-, SmartParts-, WorkItems- and WorkSpacesCollection of a WorkItem.

To iterate for example through the WorkItem.Workspaces use the following snippet:

foreach (KeyValuePair<string, IWorkspace> item in workItem.Workspaces)
{
    System.Diagnostics.Debug.Print(item.Key);
}

Go to the p&p Smart Client Guidance Community Site, download the current release and start playing with the samples out of the Smart Client Contrib package. They rewrote the original BankTeller sample. By comparing the original BankTeller sample with the one out of the SCSFContrib you'll see the advantages of a WorkItemController over a typed WorkItem.

The samples just show you what you can do with CAB, but to start developing your own app you need a deeper understanding of its mechanisms.
Therefore, I would propose to read the introduction of Rich Newman - it is the best I ever read. To me, it was most important to get a comprehension of the WorkItem and how it is used by SCSF (WorkItemController). Don't reduce it to a representation of an "use case", it is much more.

To build an application with CAB rely on Workspaces (CAB), the WorkItemController (SCSF), SmartParts (CAB), Services (CAB), Events(CAB), Commands(CAB) and Actions (SCSF). Don't use UIExtensionSites and the WorkItem.State.

About two years ago I started to write on the n-th iteration cycle of a software bundle. In the latest iteration, the bundle consists of a remote client with offline capabilities, a portal and several administration tools.
Back in 1996 we implemented the first "remote" client with MS Access and feed it on a daily basis with text files out of a existing Bulletin board system (BBS). I don’t know when the BBS was installed (1993?), but we replaced it in 1998 with an internal website based on the Microsoft DNA (VB and COM+). Due to the fact that our "remote client" only understood the text files delivered in the format defined by the BBS and a limited budget we had to stick to the old format. Between 2000 and 2003 the internal website was used to provide additional functionality and data to the remote users. Therefore several administration tools where needed and implemented. In 2004 the headquarter moved to SAP but the remote client still needed its data in the old plain text format. So we did the "cheap" solution and transformed the data delivered out of SAP back to the format defined with the BBS. According to the fixed length of the columns we lost a few characters but the data was delivered readable enough :-)
For the latest iteration of the whole software bundle we could easily describe what we needed: A loosely coupled architecture, offline capability, modules which could be used in a client and a administration context, easy deployment, a common ui design.
I was looking around and found Spring.Net, Castle Windsor, PicoContainer.Net and CAB. We decided to implement our new software with the Composite UI Application Block. So in my next posts I will publish my CAB-lessons learned.