Showing Dialogs?

Topics: CAB & Smart Client Software Factory
Jan 3, 2007 at 2:45 PM
When I first started using CAB (way back when) I went the easy route and made my dialogs inherit from Form, rather than making them UserControls. How do you guys handle this? I saw there is a WindowWorkspaceExtended and was wondering if you guys ran into any problems with this (canceling the closing of the windows, etc.).

Thanks!
Jan 3, 2007 at 3:49 PM
We use WindowWorkspaceExtended with our application, and for the most part it works pretty well. The part I don't like is having to create a WindowSmartPartInfo object to set properties on the container window, because it severely limits what you can do. But again, it serves its purpose. When it's time to close the window, you can either call OnClose() on your view, or use the WindowWorkspaceExtended.Hide() method, passing in a reference to your view, which the CAB then disposes.
Jan 3, 2007 at 7:36 PM
Hello,
What exactly do you mean when you say it severly limits what you can do?
Jan 4, 2007 at 10:53 AM
What is WindowWorkspaceExtended? I know of the WindowWorkspace but can't find any reference to what you guys are talking about?
Jan 4, 2007 at 12:19 PM
Check out the UI project in the BankBranchWorkbench sample application.
Jan 4, 2007 at 1:04 PM
One thing I noticed thus far is that I am showing some of my smartparts using the workspace as 'non-modal', so in my presenter, I wire up to the smartpartclosing event and if i have two of the same smartparts showing at a time, the event gets fired twice.
Jan 5, 2007 at 2:33 AM
Okay, now I know what this is referring to. It's clever that they embedded the SmartPartInfo object in the workspace and have it available anywhere they need a modal dialog (Going to use this idea myself now).

Anyways, going back to the original question. SCSF and CAB use the concept of views via SmartParts (UserControls) as forms have extra baggage attached to them you don't need (and in the case of a workspace easier to display a UC than a form). So it's a shift in how you think of getting input from the user (just like the concept of using MVP instead of traditional methods). Nothing wrong with it and you'll probably find the UCs are much easier to deal with.
Jan 5, 2007 at 12:24 PM
Ok, i can't find a decent way of knowing when a smartpart in a window workspace is closing. i can handle the smartpartclosing event, but if i have two smartparts showing in the workspace at once (non-modal forms), they both handle the event if either one is closed. am i missing something here?
Jan 5, 2007 at 10:43 PM
- What exactly do you mean when you say it severly limits what you can do? -

I mean that the WindowSmartPartInfo object only has a handful of properties that you can set. If you want any more control over your window than size and location, and a few other things, you will need another approach. Already in our application we have switched from using the workspace to using a regular Windows Form, just so we have total control over the behavior of that container Form.

- i can handle the smartpartclosing event, but if i have two smartparts showing in the workspace at once (non-modal forms), they both handle the event if either one is closed. am i missing something here? -

You're not missing anything. That's pretty much how CAB events work - every instance of a particular object receives a copy of the event, if they were added to the same WorkItem on creation. You do have some control - in the EventPublication attribute, you can specify a PublicationScope of Global or WorkItem. In my experience, this has helped in a few situations, but often you have to be more deliberate, and send some EventArgs that tell the subscribers which one of them should be responding to the event.
Jan 20, 2007 at 6:34 AM
- "the WindowSmartPartInfo object only has a handful of properties ... if you want any more control over your window than size and location, and a few other things, you will need another approach"

Why not try extending WindowSmartPartInfo? eg:

public class XtraWindowSmartPartInfo : WindowSmartPartInfo
{
public bool ShowInTaskbar
{ get { return showInTaskbar; }
set { showInTaskbar = value; }
}
}

And, in this case, extend and override WindowWorkSpace.SetWindowProperties method to make sure it happens.

- "Already in our application we have switched from using the workspace to using a regular Windows Form, just so we have total control over the behavior of that container Form"

That completely defeats the points of smartparts and CAB. It might be quick but it's not nice.
Jan 20, 2007 at 8:09 AM
In our project we are not using window workspace, because it just adds unnecessary complexity.
As far as I understood, using everything in user control, gives the possibility that when you need you can change the workspace and everything should work.

So we don't use window workspaces for dialogs, we have inherited dialogs for this. Also we don't use any control directly.

the base hierarchy we use is
Form
+-BaseDialog
|
+-DetailDialog (For iterating detail records)
|
+-ListDialog
| |
| +-FindDialog
|
+-TreeDialog


(used in workspaces)
UserControl
+-BaseView
|
+-ListView
|
+-DetailView



Jan 22, 2007 at 12:50 AM
A bunch of people here are advocating not using Composite Smartparts while using the Composite UI framework. I suppose you can modify a porsche to have pedals and 3 wheels too... maybe 4 wheels on a porsche just "adds unnecessary complexity?"

I'm not sure we should let others trying to learn about CAB on this forum, get the impression there's anything good about doing this - or that it's somehow necessary.

It's easy to short-change the whole CAB framework; you can use Windows.Forms for everything, ignore Model-View-Presenter and create a crappy design any way you like.

Why doesn't someone post here something that they are doing with a Windows.Form that they can't do with a WindowWorkspace, and we'll see if we can work it out.
Jan 22, 2007 at 4:14 AM
Why is inheriting from Form breaking MVP? I'm not challenging you, I'm simply asking.
I still have a presenter, I still have an interface to my form.

This works fine for me and I'm trying to understand why this is not "CAB Legal" and should be avoided.

I would appreciate any light you can shed on this issue.

Thanks,
Steve
Jan 22, 2007 at 8:41 AM
"adds unnecessary complexity?"

I'm not telling that using composite smartparts is bad, but I really don't see any benfit on using them on modal dialogs, when I know I won't use in other containers, but if I have the same SmartPart I want to reuse, by showing either in DeckWorkspace or in window, then this is great place to use this.
All depends...


But consider these 2 samples
1) I'm using window workspace
CommandHandler(Constants.CommandNames.ShowCallbackForm)
public void ShowCallbackForm(object sender, EventArgs e)
{
Microsoft.Practices.CompositeUI.WinForms.WindowSmartPartInfo info = new Microsoft.Practices.CompositeUI.WinForms.WindowSmartPartInfo();
info.Title = "Call later...";
info.Modal = true;
CallBack callBack = WorkItem.SmartParts.Get<CallBack>("CallBack");
if (callBack == null)
{
callBack = WorkItem.SmartParts.AddNew<CallBack>("CallBack");
}
WorkItem.WorkspacesWorkspaceNames.ModalWindows.Show(callBack, info);

// now how to handle close dialog results ???
// option 1 use extra Event pub/sub
// option 2 execute some command
// option 3 Extend SmartPartInfo, Extend WindowWorkspace, to responde info to SmartPartInfo


}


2) Or I'm using inherited winform dialog
CommandHandler(Constants.CommandNames.ShowCallbackForm)
public void ShowCallbackForm(object sender, EventArgs e)
{
CallBack callBack = WorkItem.SmartParts.AddNew<CallBack>("CallBack");
System.Windows.Forms.DialogResult result=callBack.ShowDialog();
if (result == System.Windows.Forms.DialogResult.OK)
{
//do something when OK pressed..
//or this can handled in extended presenter
}
WorkItem.SmartParts.Remove(callBack); //this removing part can also be done in presenter side
}
Jan 22, 2007 at 9:15 AM
I'm not telling that using composite smartparts is bad
... sorry I ment WindowWorkspace
Jan 29, 2007 at 4:55 AM
"Why is inheriting from Form breaking MVP?"

I didn't say that at all, I gave comma-delimited examples of ways you can still create a crappy design and be using CAB. I think a re-read is in order.

The first reason using Windows.Forms and not User Controls is bad that comes to mind, is that for example, our project doesn't use Windows Forms. We use a 3rd party control that inherits from Form. We'd have some fun dealing with your code with hard-coded references to Forms all over the place. We'd be right to snarl and complain that you obviously didn't follow CAB best practices. Given that in all the examples there is not a single line of code anywhere in the CAB documentation that uses Forms in place of User Controls for smart parts.
Jan 29, 2007 at 5:48 PM
My question was inspired in part by:
"ignore Model-View-Presenter and create a crappy design any way you like."

I was trying to understand if I was missing something, if there was some way that inheriting from Form braks the CAB or MVP - I still haven't seen anything that says it does. With that said, I will most likely switch over to a WindowWorkspace when I have the time.

Thanks for the response.
Jan 29, 2007 at 8:18 PM
CAB and MVP are really two different things. MVP can be used with or without CAB. It's a design pattern, nothing more.

That said, if it were me, I'd demand consistency from my application developers. If you're going to use CAB then it makes sense to use it all of the time. Maintaining a consistent architecture is good for the application and the development team. Choosing to utilize CAB part of the time, while utilizing Windows Forms another part of the time is basically bad design. It's inconsistent. If you hire developers to add to your staff in the future they may find the inconsistency frustrating.

The benefit of being consistent is that the SCSF recipes are built on UserControls. Developers on your team need only make a menu click off the context menu in Visual Studio to have the recipe create all three class files for them: interface, view and presenter. Everything gets wired-up automatically and you don't have to adjust anything to take advantage of ObjectBuilder and the DI framework.

Bottom line: consistency = good, and anyone who has to look at your code later on will thank you for it :)

Jan 31, 2007 at 5:43 AM
"I was trying to understand if I was missing something, if there was some way that inheriting from Form braks the CAB or MVP - I still haven't seen anything that says it does"

I don't really understand how someone cannot see it. You only have to read the CAB documentation and look at the examples, to see that only UserControls are used, not direct references to Windows.Form.
CAB is 'Composite UI Application Block'. Read up on the 'composite' pattern, and you will see that the thinking behind using only UserControls is to follow this pattern. If you don't use UserControls, you are breaking the 'composite' in the Composite UI. That's a pretty hard break?

I'm confused as to why you would go to all the trouble to implement a CAB project and then ignore the design recommendations and all the examples... and be surprised when someone doesn't understand why you've done it.
Feb 20, 2008 at 6:28 AM
Edited Feb 20, 2008 at 6:30 AM
Help me guys
Feb 20, 2008 at 6:28 AM
Hello guys..i need help about controlling user control in MDI application.
Currently i have an MDI CAB application which shows child form(actually child user control not form).
I can display these control as a child form in MDI window. but i can't control the resize and maximize and minimize and restore events of that control.
whu i ask this is because i put colors in user controls back ground as a background color. So, when i maximize or resize the control, the user control's color doesn't come withe the size.

and i try to solve. and fortunately i found a way. that is make the user control.size to parentform.size in user control's paint method.

but it only effects when i enlarge the control size or maximize it. but it doesn't effect when the control has been restore or reduce in size by dragging frame.

so, anyway to handle these methods/events, guys?

Please help me.

i read through MSDN, but i can't find an example or explanation. Althoug i found an example of "SmartPart QuickStart" in CAB VB.net Examples..but its not helpful to me. (I use VB.Net 2005 to develop this project)

Please Help me ASAP. Thanks
Feb 20, 2008 at 6:28 AM
Edited Feb 20, 2008 at 6:31 AM
please help me...
Feb 20, 2008 at 12:32 PM
Hi

You need to set the Dock property of the SmarPart to DockStyle.Fill. The problem is that the Form is resizing, but the User Control is not.

You may find useful the following threads:
Please let me know if this helps.

Ignacio Baumann Fonay
http://staff.southworks.net/blogs/ibaumann/
Feb 20, 2008 at 1:47 PM
Thanks "ibaumann"...
i got the idea. Thank u very much :)

but the when i set the smarpart dock to fill the other issue starts. it is the smartpart(user control)'s size. i adjust the size of user control in design mode at 600x600 but when i set dock to fill and compile/build and run it, it automatially shrink to a smaller size, i think below 300x300. i don't know why? but it doesn't matter. i just pass the windowsmartpartinfo widht and size to its base. it solves all.
Anyway.. thanks ur reply and ideas. very much :) ( i hope i can ask u some other questions and problems when i can't solve )