CAB and Dialogs

Topics: CAB & Smart Client Software Factory
Feb 15, 2006 at 5:51 AM
originally posted by: delarou

What is the guideline for showing dialogs from a usercontrol. Let's say that you have a dialog, named MyDialog, with an associated controller MyDialogController. From the usercontrol, named MyUserControl, you need to show the dialog.
Is it a best practice that in the workitem (MyWorkItem) you have something like

public void ShowMyDialog(int orderid)
{
MyDialog dlg = this.Items.AddNew<MyDialog>();
dlg.OrderId = orderid;
dlg.ShowDialog();
}

And that the controller of the the usercontrol MyUserControl has the following logic?

public void ShowMyDialog(int orderid)
{
((MyWorkWorkItem)this.WorkItem).ShowMyDialog(salesfileid);
}
Feb 15, 2006 at 10:32 AM
originally posted by: ChrisHolmes

I don't know that it's necessary to have the WorkItem create and show the Dialog. That seems like too far to bubble up the event, unless it's a fairly complicated Dialog that is doing a lot of processing. My gut reaction, on a simple Dialog at least, would be to have the Presenter/Controller of the UserControl create and show the Dialog, because it is probably the layer that is going to be most interested in the Dialog result, no?

Interested in other people's thoughts on this as well, it's a good question.
Feb 15, 2006 at 10:44 AM
originally posted by: PProvost

Have you experimented with making the "dialog" actually be a user control and present it in a WindowWorkspace exposed from the Shell?
Feb 15, 2006 at 11:11 AM
originally posted by: DLorenz

Well, he is showing the dialog on the WorkItem because he wants to inject it. I guess you could inject it from the controller because it has access to the workitem, but its not as straight forward.

Personally, I only use dialogs to show read-only data or prompt the user for data and then pull it out of the dialog afterwards. In other words, you shouldn't need to inject it. You can just show it as a normal dialog. Besides, no events are going to be fired because the user can't interact with anything except the dialog until they close it. Though, you could have other threads throwing off event publications, but would you really need your dialog to catch those?

I don't think he can use the WindowWorkspace because it wouldn't be a dialog. It would just sit there, allowing the user to go around it, right? Or is there a mode you can set to make it do a ShowDialog instead of a Show?
Feb 15, 2006 at 3:18 PM
originally posted by: delarou

In our project, a dialog can rely on services. For example a dialog can contain a combobox with countries, then I would like from the controller that I can access the services for filling the combobox. That's the reason I want injection.
Another way of doing it, is by creating the controller in the usercontrol (MyUserControl) and passing it to the dialog (MyDialog)

private MyUserControlController myUserControlController;
private MyDialogController myDialogController;

CreateNew
public MyUserControlController Controller
{
set { myUserControlController = value; }
}

CreateNew
public MyDialogController DialogController
{
set { myDialogController = value; }
}

private void OnButtonClick(object sender, EventArgs e)
{
MyDialog dialog = new MyDialog();
dialog.Controller = myDialogController;
dialog.ShowDialog();
}

I am not sure if this is conceptually a good solution or not, or that maybe going through the WorkItem is conceptually better. The first impression is, that there must be a more elegant solution.

Or maybe introducing a UIDialogService, where all dialogs throughout the application can be called?
Feb 15, 2006 at 3:24 PM
originally posted by: ChrisHolmes

Ah, I see the need now!

If your Dialog needs Injection then I would tend to treat it (conceptually) like a separate UserControl. In that case, the WorkItem is the umbrella that handles all UserControls, and I'd have the WorkItem create the Dialog, Presenter/Controller and handle disposal of it as well.

I look at the WorkItem as a higher level Controller. It makes sense to me to treat the Dialog like any of the other UserControls that the WorkItem would be managing.
Feb 15, 2006 at 4:13 PM
originally posted by: matiaswoloski

Indeed that's the way it's handled in the AppraisalWorkbench 1. The following code is part of the root work item of the module.

AvailableAppraisalsView view = WorkItem.Items.AddNew<AvailableAppraisalsView>();
view.ShowDialog();
WorkItem.Items.Remove(view);
view.Dispose();

However the view is derived from Form, not from UserControl. Notice also that the view needs to be removed from the workitem and also disposed.

1http://www.gotdotnet.com/codegallery/codegallery.aspx?id=941d2228-3bb5-42fd-8004-c08595821170

Matias
http://staff.southworks.net/blogs/matiaswoloski
Feb 16, 2006 at 9:21 AM
originally posted by: MichaelBouck

Here's how we're handling it (via injection) works great!

public static class CabUtility
{
public static DialogResult ShowDialog<T>(WorkItem parentWorkItem, IWin32Window owner)
where T: Form, new()
{
Form form = null;

try
{
form = parentWorkItem.SmartParts.AddNew<T>();
return form.ShowDialog(owner);
}
finally
{
if (form != null)
{
parentWorkItem.SmartParts.Remove(form);
}
}
}
}

In some view code:

CommandHandler(CommandConstants.APPROVE_APPLICATION)
public void OnApprove(object sender, EventArgs e)
{
if (_parentWorkItem.Status == WorkItemStatus.Active)
{
CabUtility.ShowDialog<ApprovalForm>(_parentWorkItem, this);
}
}
Dec 16, 2007 at 1:33 AM
Edited Dec 16, 2007 at 5:29 AM

gdngenericuser wrote:
originally posted by: matiaswoloski
Notice also that the view needs to be removed from the workitem and also disposed.


Why does the view need to be disposed?
I gather this is not required if you've got a DialogResult on the View?