I'm not sure if this is a bad way of building an application but let's say I have 30 WPF Windows for different screens in my application. I want to build them into a DLL so I was wondering if it is bad design to instead of creating each window as a window, if i can have 1 window that hosts whichever screen is open. So the windows will actually be a usercontrol, or at least act like one.
So when you want to go to a different screen, you would just change the content of the 1 window to the content of the "usercontrol" that you want displayed. Does this make sense, or can you see issues with possibly doing this? Thanks.
That may be a good approach but you need to think about whether every screen belongs in the same window. For example is every user control going to use all of the space in the window, or will you have some visual issues? The content of your windows, your data, and how the windows manipulate that data may also have an impact.
You may want to look into design patterns such as MVC and MVVM (more popular with WPF).
This sounds like a much nicer solution than 30 separate windows :) Nothing wrong with it.
You might want to do some reading about presentation patterns to get a good understanding of how to manage applications with multiple screens. Take a look at this excellent (but incomplete) wiki on Presentation Patterns, based on a book in the making by Jeremy Miller with contributions from the great Martin Fowler.
Read through a summary of each of the patterns to get an idea if it applies to your situation, and if it does try Googling around. Many of the patterns in that wiki have evolved fairly recently and the best resources for them so far are disparate blog entries and obscure mailing lists. But it's worth doing the digging because there are some truly inspired gems of information to be found in this arena. Presentation patterns are a very interesting thing!
From what you told I'm thinking that maybe Pages are better for your use than controls. In that case you can user Frame control in main window to support navigation between pages (or hide navigation buttons and navigate from code directly).
Related
As part of a school project, a group and I will develop a Windows application using C#.
We are not very experienced in C# but has some basic understanding for it. We do however have experience from other languages and platforms.
We would like to build an application in which the layout is split into two primary parts: the menu, which will reside to the left and the content which will be to the right.
The menu will be more or less static and when an entry in the menu is chosen, the content will be changed.
We have not been able to figure out the best way for achieving this nor have we been able to find good material on this. The idea is to have one window and add a view (as far as I can understand, this should be a UserControl?) to this window. This control will be the menu.
Now, our question is if anyone can point us in the right direction to achieve the navigation in the program. Say, when a menu entry is clicked, how will we change the content of the window and how will we manage which view is active? I suppose that every view (in the "content area") will have a controller.
We are interested in the "best practices" for this when using WinForms and the MVC pattern.
We hope that someone can help us further in this project.
If I were you I would seriously consider using WPF instead of winforms.
It, and the use of the MVVM pattern, allows you to do some pretty impressive stuff with far less code than if you are using winforms. If you don't already know winforms then it might also be a slightly less steep learning curve as WPF is a better thought out framework (at least in my opinion).
If you go the WPF route spend some time getting to understand how bindings work and how to bind your ViewModel to the UI. Once you have a good understanding of proper UI separation you are able to do far more than you could with the old WinForms framework.
I found this link quite useful when I first started looking at WPF. Especially the RelayCommand.
If you are using Winforms the options that you have got is:
-dynamically clearing forms and generating content on menu navigation
-using mdi container form, which can be parent to a number of child forms
If you are using for WPF you could use Pages in a Frame control loaded based on used menu selection. You could also use MVVM pattern to build your app.
How can i manage Autorotation Windows 8 Apps.
I have gone through the "Rotation" Sample from MSDN but it is hell lot confusing, what I need to do is , I need to have completely different view when in Portrait and a diiferent one in Landscape.
I have designed my view for Landscape when I need to make changes for Portrait View. I need a way to dynamically switch between to views of re-shuffle the views.
By far the easiest way to deal with this is to inherit your page from LayoutAwarePage instead of Page and leverage the Visual State Manager inside of Expression Blend to do all of the work for you.
I have a full article with lots of pictures and a downloadable sample application here:
http://jaredbienz.wordpress.com/2012/04/22/wp-to-w8-view-states-using-visual-state-manager/
You're definitely going to want to use a FlipView control here. I don't know if you're using JavaScript/HTML5 or C#/XAML, but it is available in either case.
There's a great sample on MSDN to show you how to do it, but without more context on your issue, I don't know how much more I can assist.
http://code.msdn.microsoft.com/windowsapps/FlipView-control-sample-18e434b4
You can handle orientation changes in two basic ways...
1) The brute force approach. Wire into the orientationchanged event...
Windows.Graphics.Display.DisplayProperties.OrientationChanged += DisplayProperties_OrientationChanged;
In the event handle, check the orientation and navigate to a page that has been specifically layout out for that orientation...
if (Windows.Graphics.Display.DisplayProperties.CurrentOrientation == DisplayOrientations.Portrait)
this.Frame.Navigate(typeof(PortraitPage));
Pros... easy to design pages optimized for given orientations
Cons... need to handle navigation and state data between pages
2) Create a single page that changes its layout using visual states. You would still wire into the orientationchanged event, but make calls to VisualStateManager.GoToState(this,"Portrait",true).or something similar depending on how you name your visual states.
Pros... change layout without navigation and you can add cool animations easily
Cons... more complex layout could be harder if you are not comfortable with advanced xaml layouts and viewStates
If you look at the sample templates (besides blank) they include a LayoutAwarePage that handles the viewstate transitions for you, simplifying things a bit.
I'm writing a WinForms based application for Windows Mobile, targeting the CompactFramework 2.0 and coding in C#.
My application has a menu which the user can select severeral job functions from.
My question is this:
For the job specific screens, should I load a UserControl into a panel in the main form, or is it better to open a new form on top of the main form?
They both seem to meet my needs, and I don't know if there is a "right" answer here.
Is one method more correct than the other?
Forms are Controls (just look at the inheritance chain), and a Form itself doesn't have a whole lot of overhead in and of itself. It creates a native Window, but that's about it.
What should drive your decision is how you use and display your UI elements in your solution. Forms are conducive to many UI architectures, and they're what most developers are familiar with. The designer supports them well, and creating, showing, hiding and closing Forms is a well documented, often used paradigm that works just fine. Yes, you have the load penalty whenever a Form is created as it creates all of its contained controls, but you're going to pay that even if it's a UserControl. The child controls have to be created in either case.
One might argue that Forms require that you recreate them every time, but that's not true. If you use ShowDialog or Hide instead of Close, you can reuse your Forms and pay the price once. The advantage here is that the Form holds your Controls in teh collection and manages all of that for you, so you have little to worry about with the GC and remembering what roots you have alive.
The UserControl paradigm is more complex - you have to manage loading and unloading controls yourself to keep memory pressure low. Complexity also increases cost - cost to maintain, cost to support, and likely cost to develop. However there are some clear advantages to UserControls in some scenarios too. If you use an MVC/MVP pattern and some form of framework that handlesyour Views, a USerControl makes a really good View with the Form becoming the Workspace (the SCSF for the desktop is a classic example of this, and so is the OpenNETCF.IoC framework for the CF).
So which is "better"? It depends on how and where you're using the elements, how your team is already doing development, and how you've architected the solution you're plugging in to. In short, the is no one right answer.
In my experience, depending on your hardware, loading controls far outperforms launching distinct forms. Our devices (Motorola WT4090 with 32meg) have no hardware acceleration, and drawing complete forms seems to really tax them. There is as much as 4-6 second delay any time a form is launched; controls, however, are almost instantaneous.
Maybe the best answer is to create a series of user controls and experiment with loading them onto the main form. It should be a fairly easy matter to then try to create a series of forms that have just the user control to see if you can improve performance.
If you don't see any performance benefit either way, it seems that it would just be a matter of preference.
Use Forms. It's the way the other applications behave. It's the way the user expexts your application to work.
Look at the pre-installed "Contacts" application: On startup you get a contact list. Once you select a contact, a new form is being opened on top of the current window. It's showing all the contact's details. Selecting "edit" from the menu will open yet another form, allowing you to edit the contact. The "Tasks" applicatoin behaves just the same way.
So the user knows: Clicking somewhere will open up a new form, and closing that form will get me back to the last form. You should work with that knowlegde rather than against it. When you use a single form, the user might repeatedly close it while he actually wanted to get back to tha last form.
From a performance point of view I find that forms open fast enough (<1 sec) on my WM 5 and my WM 6 devices.
And while it's possible to achieve form-like behaviour with UserControls, it seems more straitforward to use forms when you need form-like behavior.
So my bottom-line is: Use Forms!
P.S.: There's a good article on CodeProject on : How to create MDI Application in Compact framework
Depends on the complexity of the form/Control. Going the UserControl route will provide better performance as you will not have all of the form create functionality to also deal with.
My advice is to create a new Windows Form for every different logical action. If you need a form that is logically independent, then is better to have a separate Windows Form for it.
To speed things up you could construct all your forms in application's start up. This way you will have a delay when your application is launching (most users will be OK with this), but afterwards everything will run faster.
I have a winforms application where users will be creating stock items, and a time of creation there are a number of different things that need to happen.
I think the UI for this should probably be a wizard of some kind, but I'm unsure as to the best way to achieve this. I have seen a couple of 3rd party Wizard controls, and I have also seen manual implementations of making panel visible/invisible.
What are the best ways that people have used in the past, that are easy to implement, and also make it easy to add "pages" to the wizard later on if needed?
I know this answer has already been accepted, but I just found a better Wizard control that's free, and of course, since it's on CodeProject, includes the source, so you can modify it if it's not exactly what you want. I'm adding this as an answer for the next person to stumble across this question looking for a good Wizard control.
http://www.codeproject.com/KB/miscctrl/DesignTimeWizard.aspx
Here are a few more resources you should check out:
This DevExpress WinForms control: http://www.devexpress.com/Products/NET/Controls/WinForms/Wizard/
A home-grown wizards framework: http://weblogs.asp.net/justin_rogers/articles/60155.aspx
A wizard framework by Shawn Wildermut part of the Chris Sells's Genghis framework: http://www.sellsbrothers.com/tools/genghis/
Use a tab-control inside a form.
Change back color to "Control" in all tab-pages.
Set "appearance" to flat buttons to get rid of the white border-stuff.
Hide the tabs by sizing the entire control so that the tabs gets pushed up "under" the title bar of the form. If you need other controls (or banner maybe) above the tab-control, then instead hide the tabs with a panel-control or similar.
Childplay to code logic for back/next buttons and very easy to extend with new pages.
Take a look at this article on MSDN about "inductive user interfaces". It describes a framework (and provides the code to download) based on UserControls that give you "navigation" within a form. Perfect for designing wizards.
The easiest way to create a wizard dialog is to use one of the third-party versions available that handle all of the "hard stuff" (the page navigation, UI framework, etc.) for you. The one I like the most is from Divelements; they have both a WinForms and a WPF version.
I'm working on moving a client/server application created with C# and WinForms into the SOA/WPF/Silverlight world. One of the big hurdles is the design of the UI. My current UI is MDI driven and users rely heavily on child windows, having many open at the same time and toggling back and forth between them.
What might be the best way to recreate the UI functionality in an MDI-less environment? (I've no desire to create MDI functionality on my own in WPF). Tabs? A list panel that toggles different controls?
Look at 37signals and how nice their web UIs are (mostly HTML + AJAX). It's a good example of web applications that work. One of the things to remember are to make sure you don't break the web paradigm. If users want to see two things side by side, they should be able to duplicate the window and let the web browser do the windowing.
For WPF, there are a lot of new visualization paradigms. You can find some examples on the sites for various control toolkit providers: Xceed, Telerik, Infragistics. They have demo programs for the different ways they help you organize screens in an application.
When developing complex composite applications in WPF, you could also start at the Patterns and Practices Prism site. It's an InProgress set of practices for planning and developing complex composite (smart client style) applications in WPF.
I think the answer is really going to be up to your users -- I'd set up some prototypes with multiple paradigms and let them provide some input. The last thing you want to do is introduce a new UI paradigm without having any end-user input.
Tabs are really popular now, but don't allow side-by-side viewing, so if that is a requirement you may want to go with more of an outlook-style setup, with multiple panels that can be activated, hidden and resized.
One thing that you might want to do is to code your app as a composite UI, where each view is built independently from its container (be it a child window, tab or accordion, etc.), and is just "dropped in" in the designer. That will protect you from when the users change their minds about the navigation paradigm in the future.
multiple top level windows are easy to implement and have all the advantages of MDI - that's what MS selected for the newer versions of Office
Did you try GOA WinForms?