Modal Dialog Question? Confused???

Topics: CAB & Smart Client Software Factory
Jul 15, 2007 at 2:19 AM
Hi,

I've recently read an article on how to create a Modal Dialog. Great article by the way but when I try to get further with the concept I started to get confused and I know I've gone blank on the all thing. I'm trying to achieve a Property Page Window made up of tabs displaying various options, bit like the one you get in windows explorer when you right click on a file or folder.

Can someone clarify what needs to be done in order to achieve this:

1. Shells loads up various modules.
2. Display a dialog box (module) containing a tabworkspace.
3. Load various smart parts in the dialog box

1. Shell loads up various modules. This I guess should all specific modules except for the dialog box (PropertyPageView) module and its relevant smartparts.
2. When the user clicks on a button (for now, it will be a treeview node eventually!) contained within a specific module (moduleA) , I want to display a dialogbox which is an actual module (moduleB) containing a tabworkspace. The code below does that, but I then realised I must be doing something wrong as I have a reference of ModuleB in ModuleA and I thought the idea behind SCSF was everything to be loosely coupled and therefore have no reference between modules.

Dim view As ModuleB.PropertyPageView = WorkItem.SmartParts.AddNew(Of ModuleB.PropertyPageView)()
Dim Info As WindowSmartPartInfo = New DialogSmartPartInfo

Info.Keys(WindowWorkspaceSetting.StartPosition) = FormStartPosition.CenterParent
Info.Keys(WindowWorkspaceSetting.FormBorderStyle) = FormBorderStyle.FixedDialog
view.InitSmartPartInfo(Info)
WorkItem.Workspaces(Constants.WorkspaceNames.ModalWindows).Show(view, Info)

3. Assuming I sort problem in 2), and ignoring it for a moment, once the dialog box is displayed, I want to load multiple specific smartparts into various tabs? How do I do this? I tried with the addviews but that does not seem to trigger when called with the code above? Why, I don't know. The only way I managed to do this was to use the OnViewReady in the presenter but once again I added references to all the different module which I believe is completely breaking the purpose of being able to load up additional module at run-time without knowing anything about them.

I hope the lot makes sense. Anyone could shed some light on this would be great.

Thanks.

Thierry
Jul 15, 2007 at 2:58 PM

1. Shell loads up various modules. This I guess should all specific modules except for the dialog box (PropertyPageView) module and its relevant smartparts.


I do not know if you are aware, but a module in CAB refers to an assembly. A .dll. Assemblies should contain all logically related code (essentially WorkItems and Views/Presenters that are related). Make sure that the code that you want to place in a separate .dll is really supposed to be separated.


2. When the user clicks on a button (for now, it will be a treeview node eventually!) contained within a specific module (moduleA) , I want to display a dialogbox which is an actual module (moduleB) containing a tabworkspace. The code below does that, but I then realised I must be doing something wrong as I have a reference of ModuleB in ModuleA and I thought the idea behind SCSF was everything to be loosely coupled and therefore have no reference between modules.


I think the only thing you're doing wrong here is referencing the views in the workitem that is responsible for showing the tabview. Like you said, the fact that the assembly has references to the other modules should be a code smell immediately.

What's wrong with your design is that you are having the wrong workitems making the decision for showing the views that belong in the tabworkspace.

I'm going to break this down into labeled pieces so the rest of my comments make sense.

PropertyModule : contains PropertyEditWorkItem & PropertyTabView (contains TabWorkspace)
ModuleA : contains PropertyPageA
ModuleB : contains PropertyPageB

Shell: contains WindowWorkspace

So, from the code you included it seems that the PropertyEditWorkItem is responsible for showing the views, which means you've referenced ModuleA and ModuleB so that it knows about PropertyPageA and B.

What really needs to happen is quite the opposite.

When PropertyWorkItem runs it should register it's TabWorkspace on the PropertyTabView in the Workspaces collection of the RootWorkItem. You can manually register workspaces by doing a Workspaces.Add()

That should make the TabWorkspace available to all other workitems in all other modules.

What can happen then is akin to when a WorkItem wishes to show a view in the Shell. It knows about the Shell's workspaces because they've been registered in the Workspaces collection, so you can always do this:

Workspaces"ShellLeftWorkspace".Show(someview)

Well, the principle is the same with the TabWorkspace for the PropertyTabView. Once it is registered the other workitems know about it and can show their views in it:

Workspaces"PropertyTabWorkspace".Show(PropertyPageA)

So the workitems in ModuleA can show their own views (PropertyPageA) in the TabWorkspace. This makes it so that only the modules need to know about their own views, and the TabWorkspace becomes an aggregation of views that wish to show themselves.

From that point you just need to manage Save functionality (probably by having the PropertyWorkItem fire an event that all of the other workitems in the other modules listen for, so the presenters of those property views know to save whatever date their view contains).

I hope some of this made sense. If not, you can always email me: cb.holmes@gmail.com

-Chris