update control on another page windows 8 metro app c# - c#

This is a basic process that I cannot find any info on in Google or reference books on my Kindle account.
In regular forms applications pre-Windows 8, if you are on form 2 and you want to update something on form 1, you just type:
form1.Default.controlOnForm1.text = "updated text";
This does not work in Windows 8.
Thank you.
UPDATE:
I found an easy way to do this in cases when databinding does not do what I need. I simply create a static copy of the control I need to access. Say Button1 on page2 needs to be accessed on page1.
At the top declare:
public static Button statButton1;
in the loaded event I create the relationship between the static copy and the button in the XAML code:
statButton1 = Button1;
And then easy as pie, you can access the button anywhere:
page2.statButton1.Width = 48;

Windows 8 apps (or any other XAML based apps) are usually made using the MVVM Pattern. I really recommend you read about it and do the same. This pattern leads to less coupling in the application and makes it easier to develop and maintain.
The type of changes you are talking about here would be done by setting a property on the ViewModel (VM), that in turn, notifies the View (UI) with a PropertyChangedEvent so it can refresh itself.
To allow the ViewModels to set each others properties, they would all need to know about each other, which in turn leads to high coupling. This is usually solved by using an EventAggregator or MessageBus which sends messages/events between objects (without them knowing about each other) based on a subscribe/publish pattern.
To start out I would look at An Address Book Application Made in MVVM for Metro. This is a basic example which shows the usage of this pattern without any frameworks.
Once you feel comfortable with the MVVM pattern, I would suggest you use a framework like Caliburn.Micro or MVVM Light. These frameworks offer lots of great stuff for building applications with the MVVM pattern.

Related

Change view when using WinForm and MVC

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.

Metro-style application UI design: Pages vs Scenarios

I'm working on a windows 8 metro-style app, using developer preview for an academic project at university. We have to use MVVM pattern.
In the main Page we have a metro-style main menu with buttons. Each button leads to an application facility (ie. 'Show my Library', 'Show Favourites', ...) which should belong to a different View, according to MVVM pattern.
In your opinion should we create a new 'metro-style Page' for each View or expect a 'Scenario' for each use case refreshing the main Page, like those present in many example apps?
In other terms, using MVVM should there be a 1:1 match between 'plain old WPF Windows' and 'brand new metro-style Pages'?
The thing with MVVM is that there are no hard rules as to what constitutes a View other than the fact that it is the means by which the user can view the ViewModel data.
A View need not be a Page, but can be a Control. Thus you can have one page, on which many View controls are displayed, if you wish. Quite often I have my Views as controls, even if they are to be the sole item displayed on a page, as it allows me to embed them in other pages more easily at a later date.
The MVVM pattern is purely a means of separating the UI from the business/code logic. A ViewModel class doesn't care how it's data is displayed, it just provides the binding points, properties etc., for the data to be displayed and trigger points for code function.
Some people will insist that there is never any code in the code behind files, but I think that a more pragmatic approach is required. Code that controls visual aspects of the View is fine, and there are occaisions when what appears to be business logic intrudes.
For example when implementing drag and drop functionality code will be required in the code behind. This is really just a visual aspect so no problem there, but if the business model dictates that only certain items, or a maximum number of items are dropped in a given location then the ViewModel will need to provide some data binding points that the View can use to implement this. By doing so you could argue that the View code behind now implements some business logic.
So back to your original question. I would try to implement the application such that it behaves as is expected for a windows 8 metro-stryle application. This will obviously have a bearing on how you code, but it should still be possible to stick to the MVVM pattern when doing so.

Handle navigation between several view in a WPF application

I've done several WPF application(not using MVVM) in the past and I had always to implement my own system of navigation between view(instantiate the view once, and then load in a container component, with refreshing required components of my view).
It works, but:
It's always custom, so if a new developer comes he has to learn of it how it works
I'm pretty sure that It's not the most optimized(most of things haven't been done in background worker, ...)
It's a time loss
So I was wondering if there is an official way to handle this ? I don't exactly how, but I was thinking to a navigation component, which can act a little like a tab panel, or a little like the MVC framework in asp.net, we can call a specified controller for an action and some parameters.
Maybe deactiviting bindings when they aren't in the current view
You can use DataTemplates/Styles to customize content of your control ( not only apearance, but data, cause that what you're asking for I presume)
http://msdn.microsoft.com/en-us/library/ms742521.aspx
You can have one Host control and at runtime change its appearance based on events/ states.
Like an example can have a look here:
http://code.google.com/p/svnradar/ how this program manages a appearance of Group and Flat view of repository information.
Another example:
Podder of Josh Smith
http://joshsmithonwpf.wordpress.com/2008/03/05/podder-v2-has-been-released/
Hope this helps.
You may be interested by Lakana, a lightweight (but powerful) framework that can handle for you all the navigation concerns !
Riana

MVVM Central App Logic

I am using Simple MVVM Toolkit in WPF to create an application, the application uses a central tab control, with a View (UserControl) for each tab item. These Views may also contain tab controls themselves containing further "sub-views".
Our difficulty is in finding a way to share application logic which is used by several of these views, without having one global huge messy class..
I would not go with a huge class which holds everything. But I would have a central ViewModel which controls the overall state. Like the ShellViewModel. And I would let the viewmodels communicate and exchange information via Messenger (MVVM Toolkit light) or EventAggregator (Prism).
They offer way vie Publish/Subscriber Pattern to exchange information. And you can address them by implementing own message classes and pass payload along with it.
So you could have a global Message for Save all and every (Sub-)ViewModel could register to it and runs there own save method after receiving the message...
Prism
http://msdn.microsoft.com/en-us/library/ff921122(v=pandp.20).aspx
MVVM light
http://blog.galasoft.ch/archive/2009/09/27/mvvm-light-toolkit-messenger-v2-beta.aspx
Let me know if this helps...

using usercontrols instead of windows

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).

Categories

Resources