I would like to know the difference between page, frame, navigation windows in c# wpf
what is the best choice of them for wpf windows application?
in my application how to make fixed part (contain main buttons) and changeable part (show pages) after clicking buttons in fixed part
are there any good websites provides video tutorials for c# wpf from beginning to professional?
thank you
A Page is much like a user control, only that is is displayed within a Frame, which again is part of a NavigationWindow. A NavigationWindow is a special kind of window that allows for page navigation and can display the respective controls for navigating pages.
A paged application is a good choice if you want Wizard-like functionality, or if the user experience should be comparable to what you get when browsing the web. In many cases, using standard WPF windows is a better choice.
The NavigationWindow already contains a "fixed part" that can contain controls. You can also use a normal window, place a Frame in it and then - through proper layout - create your own "fixed parts". Navigation would then come down to calling the navigation methods the Frame provides.
From the answer to this question:
Pages are intended for use in navigation applications (usually with back and forward buttons, e.g. Internet Explorer). Pages must be hosted in a NavigationWindow or a Frame
The best choice depends on what kind of application you want to create. Is it a wizard or navigation type application or just a regular application with one window (maybe with tabs)?
I would definitely consider using a MVVM framework like Caliburn.Micro for making a WPF application. It has some really powerful mechanisms for dealing with Screens, Conductors and Composition, in addition to encouraging you to decouple your application by using the MVVM pattern. The author of Caliburn.Micro, Rob Eisenberg, has written some tutorials with extensive explanation about and how to use the framework under the project's documentation. There is also lots of resources around the interwebz, google it! :)
I can also recommend Pluralsight's WPF and XAML Fundamentals and WPF Advanced Topics, they should cover what whatever is worth knowing about WPF :)
Related
I want to create a kiosk mode application using WPF. I want to use a single window because the user should not be able to exit this fullscreen application.
The application should guide the user trough a process. When the user proceeds trough the process, the screen should constantly change and show him the next step.
Usually I just create a single window and use a "state machine" to switch UserControls containing the information for the current step. Is there a better way to achieve this functionality? Maybe I would get a better result using multiple windows or Pages (never used them).
The reason why I am asking is that in future I want to have a simple, clean way of switching the content inside a single window. i.e. I am planning to implement some sort of animation when switching content (like sliding to the next / previous step). I don't want to put more effort into my current approach if it isn't the most flexible and clean one.
Any ideas?
PS: This is about desktop applications. Today I come from the Winforms environment and am experimenting with WPF.
There's a few ways you can achieve this.
First would be to use a Page based application, this will allow you to use a single window. Here is a pretty interesting tutorial
A bonus of using this approach is that navigation between pages is built in.
Your requirements are that you need to use animation for transitioning between pages, as far as I'm aware, using a Page based application cannot achieve this (I may be wrong). So your other option would be to use a UserControl MVVM approach.
This probably won't make a lot of sense now, but here goes:
You can use a single master view model which will hold multiple child view models, each of these could have a visibility property which dictates the visibility of the associated view. The master view model would simply be responsible for displaying the appropriate view model depending on where the user currently is in the application.
Using some clever XAML, you can create storyboards (animations) when the view becomes visible, which will allow you to achieve the crazy awesome animations that you require.
Anyway, that probably didn't make any sense, so here's a tutorial to get you started with MVVM.
Out of curiousity, is it possible to have 2 application layouts without having to have 2 projects?
Like one layout for desktop/laptops. And then one layout for tablets?
I know winforms only has 1 designer file, and that probably answers my question, but I was curious if i really just needed to re-create a whole new program for a tablet layout, even though it would have all the same functionality as the desktop, with all the same controls, just look slightly different.
I'd put the core functionality in a library assembly (DLL), and write two UI applications that reference the same core assembly.
You can write your own custom LayoutEngine which handles the layout. This way you leave all layout oriented task to your engine and can focus on code.
Here's an article on Microsoft on how to do this (with sample source):
http://msdn.microsoft.com/en-us/library/ms973821.aspx
From the article:
All Windows Forms controls provide a Layout event, along with a host
of other notifications, which enables the writing of a complex layout
code. To facilitate writing reusable layout engines, we can provide a
basic framework.
Windows Form (in C#) - I need to create a custom listbox control for the following requirement:
There is a listbox with a long list of items. I want the user to be able to click in the list, and then start typing and have it automatically take them to the matching item (I call this "type ahead"). It needs to be able to do this for as many characters as they type that have a match.
This control should be really reusable without much changes.
What are things/points I should keep in mind while developing a reusable custom control? (if you provide a good pattern as a sample... will be more helpful)
In Real World scenario the first decision should be buy vs build. if your application is a serious one and not just for hobby and there is budget for it I would check some of those great controls collections like DevExpress or Telerik for WinForms. You would need a grid as well at some point, eventually, and surely your custom or framework one cannot compete theirs.
I refer to those libraries because i believe they already have a listbox with autocomplete as you described in your requirements. check the online demos on their websites...
Using which of these is the best approach while planning Silverlight application? UserControls or Page.
My understanding is that when you have to encapsulate some of the logic of some component, which is truly generic and reusable then use usercontrol else use Page because Page is tightly integrated with browser's history etc, so you can move back and forth and can make use of NavigationService to navigate across pages because if you keep using usercontrols, it is very tiresome to navigate all the way to the required page. Thus we cannot bookmark it because it serves no purpose. We will have to again find our way through the menus in application to reach our desired location.
Is my understanding correct?
Your understanding is correct. Use Pages to integrate with the Navigation framework and the main pages and controls for custom components etc.
All in WPF:
Developing a wizard application, user has to answer a number of simple questions before brought to the main app. The main app is then prefilled with the information obtained from the wizard.
I started with a Window which I then planned to add usercontrols to. The main window would have the user control in the first row, then Next and Previous buttons to control moving between the controls in the second row. This way I could easily control the logic to switch between screens like:
WizardControl1.IsVisible = false;
WizardControl2.IsVisible = true;
But for some reason, user controls do not have setter for IsVisible. Hurray.
So then I thought I would just use seperate windows for each section of the wizard. The problem with this approach is that now when stepping between, the window opens in random positions, and by steppign through the wizard with next, the next window pops up randomly which is really distracting and frustrating.
So how can I develop a wizard properly? I don't get why this is so hard...not exactly rocket science... replacing text and controls and storing input after pressing next/previous!
Thanks
Check this link:
http://www.codeproject.com/KB/WPF/InternationalizedWizard.aspx
This is the article about building wizard in WPF by Josh Smith, it's seems to be nice pattern.
I found it's helpful for me, hope you'll too.
There is also an open source Avalon Wizard control on codeplex.
I'd probably aproach this using data binding and template selectors. Have the wizard form bind to a "WizardData" class, which exposes a list of "WizardPage" base classes.
The WizardData class can expose properties defining the correct info on the forms, and display a control for the main page that uses a template selector to determine the proper control to display based on the actual type of the particular wizard page.
It sounds like more work than it is, really. It also gives you the benefit of good separation between code and UI (all "work" is done by the WizardData and WizardPage classes), and the ability to test logic independent of the UI.
It's also a very WPF/MVVM way of approaching the problem.
I recognize this does not directly address your question, but I thought I'd mention it as a possible alternative. I've used Actipro's Wizard control with pretty good results, and when I have needed support, they have been very responsive. I am not affiliated with them in any way; I just like not having to write the plumbing to manage a wizard.
The property is called "Visibility".
I find that I do better when I dynamically add and removing controls rather than hide them.
I was looking for a Wizard solution too. I have the need to stick with stock WPF components so I implemented the wizard using a standard form and a tab control.
I only hide the tabs at runtime so there available in the IDE. At runtime just use Back, Next, Finish... to navigate thru the tab items
works good