Hardcoded workspace name in module?

Topics: CAB & Smart Client Software Factory
Jan 6, 2006 at 5:21 AM
originally posted by: _JERKER_

(I've tried to find information on this all over the message board but could not find any answer. Sorry if I'm wrong...)

In the Walkthrough QuickStart, in the MyModuleInit's Load method, the shell application's workspace is referenced by hardcoding its name. Is there another way of referencing the workspaces from an module?

From my point of view, a module is something independent, making it possible to reuse in many places. By hardcoding the workspace name, I force all the applications to name its workspace the same way. Am I right, or have I misunderstood something?

I'm new to CAB, and there is probably a solution for this!?

Best regards
Jan 6, 2006 at 8:35 AM
originally posted by: BradWilsonMSFT

It's probably fairly common to take such "magic names" and put them in constants in a globally accessable place.
Feb 9, 2006 at 2:28 AM
originally posted by: morfy

This is a question i'm looking an answer for too.

How about modules ? Those clearly shold be reusable outside the project they are created or no ?
All the samples use hardcoded values for the workspace identifier in the Load override. Should the workspace name be injected to a property or another way to accomplish this (yes the names will be constants hopefully somewhere) ? But again i guess this would mean that the module could only be used in one workspace/application (can't tell a real world example of this, so i might be chasing a what if then else what if else then ...).
Feb 9, 2006 at 6:05 AM
originally posted by: DLorenz

What I do is pass down the reference thru state automatically (I created another WorkItem that inherits from the CAB one so I can add additional functionality without modifying the CAB code). Then I can just call the property MainWorkspace. Then if you know your child workitem's MainWorkspace will be different, you can simply change it, and then run the child workitem.
Feb 9, 2006 at 7:40 AM
originally posted by: jolu1977

You can use the WorkItemTypeCatalogService. This is a bit of a reversal of relationship. Instead of having the workitem "Run(Workspace) or Show(Workspace)" in the modulae init you can register the workitem with the WorkItemTypeCatalogService then create it later in a location that has the instance of the workspace.

When using the WorkItemTypeCatalogService to decouple from specific modules create a common that will hold interfaces that describe workitems. This may be a bit different than what you are looking for but definitly gets rid of the hard coded string.
Feb 9, 2006 at 9:50 AM
originally posted by: AndrePiwoni

This is exactly approach that I came up with. It is very similar to Eclipse approach where extensions, for the most part, don't decide where they get to be placed. Client may locate them via an extension point and place them somewhere. You may think of a WorkItemTypeCatalogService as an extension registry. Modules cannot be easily unloaded so WorkItem related contributions to the menu etc. during init/load time don't seem to be a good idea, especially if you need to activate/deactivate menu item as specific WorkItem is created and destroyed repeatedly. It seems that module init/load is more for UI contributions that will persist throughout a lifetime of an application and it is a good place to register available work items with catalog service.
Feb 24, 2006 at 4:35 AM
originally posted by: pwolf

Hi jolu1977,

could you maybe give a sample of how you do this: "then create it later in a location that has the instance of the workspace" please?
The samples explain already how to "you can register the workitem with the WorkItemTypeCatalogService" (see below). But I couldn't find how to call it from the RootWorkItem

Thanks a lot
namespace MyModule
public class MyModuleInit:ModuleInit
private IWorkItemTypeCatalogService myCatalogService;
public IWorkItemTypeCatalogService myWorkItemCatalog
set { myCatalogService = value; }

public override void Load() {

Feb 24, 2006 at 6:45 AM
originally posted by: jolu1977

so, the gist of it is register a workitem.


then at a later point to use it do.

workItemTypeCatalogService.CreateEach<IMyWorkItem>(workItemToCreateIn, delegate(IMyWorkItem myWorkItem)
//do anything in here you need to with the workitems after they are created

I used an interface instead of my workitem type because I do not want a refernce between modules. The interface lives in a common assembly that the modules use. Now you know that the module that has the workitem you want to create in a delayed fashion needs to be loaded before the module that wants to use it. To do that use the Module and ModuleDependency attributes to dictate a loading order.

Hope that helps