Like Master pages in ASP.NET, do we have any similar concept for Windows Form application. So that I dont have to repeat the same portion of form (Header and footer) many times through out the application.
Create a form class that defines the components you want, and make all your other forms a subclass of this form class.
Here is a good example in VB.NET.
That is what UserControls are for in Windows Forms.
Basically, you would create the "master" form and then the master form would be initialized with the types of the user controls that would go in the "placeholders". The form would just then create the controls given the Type instance(s) and add the instances to the Controls collection.
You can create a base form class with the controls that will be on every form of that type, and then derive all of your actual forms from that base class. This is called "Visual Inheritance", and the Windows Forms designer has some nice design-time support for this.
Alternatively, you might also look into the notion of having one actual form with your header and footer fields and a big blank panel where your individual "pages" will go. Make each page a user control and swap them in and out as needed at run-time. This is a standard way of making "wizard" dialogs, for example.
Related
I'm writing a Windows application in WPF. I based my UI in a single menu and a tab control to display different documents or application forms. Since the menu as well as other things are fixed throughout the application, I need a way to display the contents of each TabItem. I have found two:
write a user control for each form, or
using a frame to display the content of each form.
The question
Is there any other single way for doing this. How do they compare in terms of clean code? I mean, in .net forms I only need load the form from the menu.
I know, I should go for any pattern like MVVM, but for this very first time I want to use the default approach.
I go with Frames and host Pages (not user controls). I like Pages over User Controls as the event model seems to have more hooks.
I'm creating a Silverlight 4 application to manage active directory objects (CRUD Users, groups etc). Now we all know that active directory objects have lots of properties.
I want to save some groups of property names in an SQL DB (ie, samaccountname, mail, etc.) for certain AD object types (users, groups, etc).
When a user in the silverlight app clicks on "create user" I want to
get all the property names I defined in the sql db for the user
create a pre defined silverlight control for each property and add it to the current "create view"
be able to read all the values the user enters in the controls and pass them on
The user controls differ depending on the type of the Active Directory property, i.e. for a property with a datetime value, we will create a user control with a calendar. This way we can keep the "Create" Views dynamic.
The Silverlight / Prism foundation is already there and I'm adding my Views via the RegionManager. It all works just fine but I'm not sure how to add controls in such a dynamic way that it still works with PRISM and the MVVM pattern. Thank you for any input.
I'm going to assume that your comfortable with the getting the properties from the db and saving the values back and focus on the middle area of creating the view with MVVM in mind.
The PRISM part I wouldn't worry about. You say you've got the views registered with the region manager and that's about all you need to do.
My initial thought was how would you "create" controls at runtime with MVVM considered. Creating controls is not the hard part but would require a handle on the element you will be injecting these into, a root grid for example. This would on the surface feel very un-MVVM. Personally I think it's valid to have "view" code done the old fashion way, it's the "data" code used in binding that should be MVVM'd. The issue is telling the code that will inject the controls on to the view what to actually inject. I can't think of a neat way to do this.
As a solution could you not create a view containing all the controls that apply to each of the properties and rather than "create" them when needed "hide" them when not needed? You could bind the "Visibility" property (probably through a value converter) to a property in the ViewModel that can be used to determine if that particular control should be shown or not. If these where placed in a stack panel then the view would dynamically shrink.
If you think a code example would help let me know.
I am writing my first wpf application now .
I want to use a NavigationWindow on each page the user make selections and all the data should be available on the next pages, I have about 6 page.
How I should path all the data ? via the constructor ? or there is some smarter way in WPF .
On the last page there will be a lot data to path from the previous pages.
I would attack this from one of two ways: The Code-behind way (Easy, but difficult to expand, also will get very messy), and the MVVM way (Takes some learning, separates concerns, easy to extend, manage).
In the code-behind way, I would just have a Tab control with the tab headers styled the way you want them (you can style them to look like just about anything you want). In the code-behind you could have some logic that specifies that X Tab is not enabled or Visible until Y criteria are met.
There is a better way, but it comes with a bit of a learning curve, the MVVM design pattern. You would have 6 Page objects that are really just CLR objects that define the contents of the page (e.g. if it is a questionnaire your page objects would contain question objects and title objects for instance).
You could have a couple of Views, a navigation View, and a page view. The NavigationView would be bound to a NavigationViewModel which would have the logic necessary to change the page. The PageView would be bound to one of 6 PageViewModels and the PageViews DataContext (which provides that binding) could be changed based on the NavigationViews logic.
Learning Prism composite application guidance for WPF Silverlight MVVM Fundamentals
MSDN Page for MVVM explanation
Night Walker,
It is difficult to make out exactly what you want to do from your explanation. First, the NavigationWindow is the frame of your application, I think you know this but I just wanted to make sure we understood that we're not creating new instances of the NavigationWindow. I think you mean 'Pages'. Pages are the content of a Navigation window and represent some target that you want to appear in the ContentPresenter that is provided by the NavigationWindow.
I'm again not sure how you are using the phrase 'Path the data'. Typically you would create Pages either directly in the project or in satellite projects and then reference them using Pack URIs. An example of how Pack URIs are constructed can be found here.
http://msdn.microsoft.com/en-us/library/aa970069(v=vs.85).aspx
You can then navigate to the pack URLs using an expression that looks like:
this.Navigate(new Uri("pack://application:,,,/MyAssembly;component/MyPage.xaml", UriKind.Absolute);
If you don't want to get involved with all the nuts-and-bolts of the framework for navigation and just want to focus on the application for your users, you can check out the professional version of the NavigationControl that I put together:
http://www.teraque.com/products/explorer-chrome-suite/
There's an free demo you can download. If this is was you are looking to do I can give you pointers if you don't want to purchase the package directly.
Sincerely,
Donald Roy Airey
donald.roy.airey#teraque.com
Can I have master form that will contain windows forms? Or even windows control?
Thanks a lot.
For a form to contain other forms, you want MDI (as Zach Johnson already said). Setting the relevant form properties (IsMdiContainer / MdiChildren / MdiParent / etc) will get you the behaviour you want.
For something like a "master page for forms", you could try using Visual Inheritance. First you define a basic "master" form layout, leaving space for the controls on the child forms. Then when you create new forms, be sure to select Add New-->Windows Forms-->Inherited Form, and Visual Studio will prompt you to select a parent form to inherit from.
You can achieve this with inheritance i suppose
I think you want to create a Multiple Document Interface (MDI). Also, all windows forms can contain controls, so you can by definition create a form that contains a control.
A winform application I work has a main form that is completely built in this manner. It uses one Winform and everything displayed on it is a user control. All the displays are written as plugins and can be pulled into the applications menu and have their user control displayed.
I am working on a little WinForm app and have been trying to find the answers to a few questions i have without any luck. Im a ASP.NET developer so WinForms development is new to me.
Here is my main question:
How do I create a menu system that once selected the contents will render in the Main form of the selected item. If its a GridView I want to the GridView to render inside the main application so they can navigate away without having to deal with the modal popup. I do not want to popup forms unless i explicitly say so. I guess the equivalent to this would be using a Master page in ASP.NET.
Make sense?
The closest thing to Master pages in winforms would be MDI (multiple document interface), which is a hideous Windows 3.1-era abortion of a user interface. Why this option is even still around, and why anyone still uses it, is beyond me.
The second closest thing (and something more acceptable as a UI) is just to have one main form in your application, and implement the different pieces of functionality your app requires as separate user controls which are displayed on the form and hidden as the context requires.
A weirder method, but one that might also work for you, is to use forms inheritance - design one "master" form with the menus and controls that you want to always be present, and then have each form in your app inherit from that master form. This would not appear to the user to be much different from my second option above, so I wouldn't bother with it.
There really isn't anything similar to Master pages in WinForms.
The closest to what you want to use would be a TabControl selecting a different tab will display that tab over the other tabs. If you don't like the tab look you could extend the TabControl to not show the tabs or hack it together by placing the TabControl inside a panel just large enough to show the content but not the Tabs and change tabs programatically in your menu control.