Main WorkItem

Topics: CAB & Smart Client Software Factory
Oct 18, 2005 at 5:45 AM
originally posted by: aaguiarz

I'm still confused about the 'main' workItem.

I have a main application with a shell, that is basically define das

public class CabApplication : FormShellApplication<WorkItem, MainShell>

Then I have a module, with a main work item, which adds commands to the shell, etc.

The problem I'm facing now is that the SmartParts in the module register its SmartPartInfo in a module's WorkItem (I also tried to manually register it in the Module's Main Work Item), but the Workspace looks for it the WorkItem used in the CabApplication... so it cannot not find it.

Thanks
Oct 18, 2005 at 9:37 AM
originally posted by: dcazzulino

Too many "mains", I'm lost ;)

Here's how it works:

- WorkItem contains a list of registered SPI
- Show(smartPart) automatically looks for a registered SPI matching the SP

There's no provision for nesting. That means that SPIs are available when you call show on workspaces that are contained in the workitem where they were registered.

I don't know what you mean by module's Main Work Item. We don't have such a concept...

HTH
Oct 18, 2005 at 10:40 AM
originally posted by: aaguiarz

;)

In the BankTeller sample, BankShellApplication is defined as:

public class BankShellApplication : FormShellApplication<WorkItem, BankShellForm>

that's the equivalent of my 'CabApplication'

In the BankTellerModule, you have

public override void Load()
{
// Register workitem so others can create it and use it.
workitemCatalog.RegisterWorkItem<BankTellerWorkItem>();
}

That is my 'module main work item' ;). It adds some UI elements (in this case, a menu entry with the list of existing entities in that module).

My workspace is created in the shell defined in 'CabApplication', so it does not know about the module work items. It knows about the generic WorkItem created in FormShellApplication<WorkItem, BankShellForm>.

When I create a smartpart, it registers the SPI in the WorkItem which created it. That's a WorkItem local to the module, so the Workspace cannot find it when it looks in the WorkItem that created the Workspace.. I want to access the ISP from a Workspace because I want to use the Description as the description of a tab page.

In the BankTeller sample, if you implement ISP in CustomerAccountsView and then want to access it from CustomerSummaryView.OnLoad by writing:

ISmartPartInfo i = controller.WorkItem.GetSmartPartInfo<CustomerAccountsView>(this.customerAccountsView1);

then you will get an empty ISmartPartInfo.

Thanks

Andres
Oct 26, 2005 at 8:55 AM
originally posted by: dcazzulino

This is a very good catch. We are already working on fixing it for RTM.

Keep the feedback coming!
Oct 26, 2005 at 11:23 AM
originally posted by: DLorenz

How are you running the other module's workitem? You have to add that child workitem to the parent, otherwise it won't pass the Workspaces down.
Oct 27, 2005 at 7:22 AM
originally posted by: aaguiarz

I have access to the Workspace.

I'm creating the WorkItems in the shell doing:

workItemTypeCatalog.CreateEachWorkItem<IShowInShell>(workItem.RootWorkItem, delegate(IShowInShell item)
{
item.Initialize();
});

It's my own IShowInShell, not the one in the BankTeller example. It looks I get access to the Workspace because the CreateEachWorkItem does:

foreach (Type extension in extensions)
{
action((T)parentWorkItem.Items.AddNew(extension));
}

Thanks!
Oct 27, 2005 at 8:35 PM
originally posted by: dcazzulino

Yes, the issue has nothing to do with accessility of the workspace, but rather the fact that when you look for a workspace, the lookup "goes up", whereas the lookup for smart part infos does not.
We have fixed this issue and made them both go up, and will be in for the next release.