How do I transfer data from one window to another modal in silverlight. I have one window, push the button and another window appears where complements sample text boxes, data from these fields I would like to have seen in the previous window.
The answer depends on what type of framework you're using. In caliburn micro with a viewmodel first approach these types of things are very simple. You just create a new viewmodel and set the proper fields and let caliburn handle displaying it for you. With other view first approaches it is more difficult. You can maybe use a Message to set the fields using something like MVVM Light. Either way we need more information on how you are building your app to answer your question.
Related
I need to build our future business applications with WPF using MVVM.
My typical application consists of several windows/tab pages with grids and form style windows. Both edit windows and grid windows can be different depending on the logged in user, so most of them will be built datadriven.
And I'm trying to write as few code as possible, as not written code is the only one to be guaranteed error free .
So, now my question: how to structure the entire thing?
The View is clear to me - is is built using XAML or by code.
The ViewModel should contain the business logic and the validation rules and should let feed the View the data, and should contain the commands for the actions.
So, where to put the data? A select returns a DataTable. Should this datatable exposed through the ViewModel to the View for the grid windows?
And for the form windows? Should the single DataRow exposed trough the ViewModel to the View?
Are there other helper or intermediate classes needed?
Thank you for any useful suggestion!
Wolfgang
Its best way to go with WPF and MVVM,
I suggest before you start go thru the basics of MVVM. for your reference you can understand better here
The preferred UI paradigm in WPF is to have tab controls and grids in a single window, something like this:
You don't have to stop there, you can nest them as deeply as you need to for the sake of clarity.
Currently I am searching for the best way for paginating the records in WPF datagrid.
I have found one best article which provide best way for paginating records in Silverlight over here.
See it provides also a fabulous demo.
Here is one screen shot.
But when I have trying it to implement it in WPF I could not implement it?
I could not found PagedCollectionView class and also could not found the alternative XAML code of the Silverlight code shows is below screen shot.
Could any one provide or suggest the best way for paginating the records in WPF
as like Silverlight?
You can grab the PagedCollectionView source code from here and compile it into your WPF project. I've done this for a WPF project in the past and it works just fine. However, you won't have the supporting types like DataPager, but it's easy enough just to write your own or throw some buttons on your view that page through the collection.
WPF DataGrid doesn't come with pagination by default. You have to have your own custom implementation. Here is a sample. The sample implements First/Previous as ViewModel commands, however I would advise you to move these commands as part of the control and make a custom DataGrid control that you can reuse across application.
I will be starting a new project soon and am looking for some architectural advice from those of you who have experience with WPF, Prism, and MVVM.
The project will definitely be WPF and I will be implementing MVVM (I will likely use Josh Smith's MVVM Foundation as a starting point) in order to be able to benefit from the separation of UI/logic etc. I am not sure though if I would benefit from using Prism as well to structure my project.
Let me briefly describe the project. There will be a main "toolbar" that will display a number of widgets. Each widget displays some basic data related to its function and clicking the widget will open a new window that will display much more detailed data and contain a rich UI for viewing/editing the data.
Now, I was thinking that I can use Prism to frame the project but I have never used it before and am not sure if it is suitable for what I am trying to achieve. For example, would my "toolbar" be a shell that contains regions that each widget would populate? Would each new window that is displayed when a widget is clicked also be its own shell with its own region setup? If I can get the pattern down for the toolbar and one widget on the toolbar, I can replicate it for the rest of the widgets.
Aside from Prism, I have a question about how MVVM should be implemented for certain data editing windows. Let's say I have a chart that displays some data and the user is able to directly click/mouse move on the chart to edit the data that he sees. All of the data is in the model and the view model is making that data available to the view via binding. My question is where will the mouse click/move events, that are specific to the chart in that view, be written? We don't want much/anything in the view's code behind and we don't want to have UI event handlers in the view model so I am not sure how this type of scenario is handled. I know that commands are the likely answer here but the MVVM samples I have seen usually show sample commands for simple button clicks. Is the general idea the same?
So, if anyone has any suggestions on the above or any general tips on working with WPF and MVVM/Prism, please let me know.
Thank you.
There are a few questions in there so I will do my best at covering them all.
I worked on a project that had WPF, MVVM, and Prism along side other frameworks. The best advice is to understand the power and functionality of each before glueing it all together. You don't have to use all the features of Prism for it to be useful in this situation.
For Prism you can use...
Shell and bootstrapper to initialise the application and load modules from other assemblies.
Create and configure Unity for Dependency Injection. You can use other DI Containers. Here you can add global services each module will use.
Use of EventAggregator to notify differnent parts of the application, usually across modules and views
Regions for naming areas on the UI so modules can add a view to a particular location.
The above 4 don't all have to be used but can easily be integrated in a MVVM /WPF application.
For example, would my "toolbar" be a
shell that contains regions that each
widget would populate?
Here you can have a region you create (you can derive from Region) that will manage the buttons on the toolbar. (I have used a region with regards to a Ribbon). A service can be exposed via an interface that each module can supply the command/image (what ever you have) that when it is clicked will create a ViewModel. You can do this inside the module's Initialisation.
Would each new window that is
displayed when a widget is clicked
also be its own shell with its own
region setup?
If each button opens a brand new window I would suggest introducing a common controller class that will create a generic use window and attach a view model that your module creates. No real need to use regions in this case unless you are gluing different views to a application window that stays open longer than the life of the view itself. The window in basic form can simply be this...
<Window ...>
<ContentControl Content="{Binding}" />
</Window>
Where within your controller it can do this...
public void DisplayView(ViewModel vm)
{
var window = new MyWindow { DataContext = vm };
window.Show();
}
The controller can be used within your module directly of wrapped within a service... although for testabilty a service and interface would be best. Make sure you have merged your module resources with the Applicaiton.Resources and use DataTemplate's to link your view to the view model.
My question is where will the mouse
click/move events, that are specific
to the chart in that view, be written?
Don't be afraid of code behind but you can in this case use EventToCommand attached behaviour that will route to a command on your viewmodel. MVVMLight toolkit has this which you can reuse if you want.
DI is very powerful and I encourage using it even without Prism as constructing your view models will be easier.
HTH
I think Prism will work great for you.
->would my "toolbar" be a shell that contains regions that each widget would populate?
Put a single region with an ItemsControl in the Shell
Create modules for each widget
Keep adding the widget modules to the same itemscontrol shell region.
The biggest advantage with this is that if you add more modules you don't need to change anything.
->Would each new window that is displayed when a widget is clicked also be its own shell with its own region setup?
No, you can use a 'WindowRegionAdapter' in the shell to create views for your widgets in separate windows.
->where will the mouse click/move events, that are specific to the chart in that view, be written?
You can use attached behaviors to bind events in your view to commands in the ViewModel purely in XAML. Google 'Blend behaviors' or 'attached bahaviors' for how you could go about doing it. There is no need to write any code behind for this.
To be honest I am only trying to give you the keywords you'd want to search to get all the information you need.
I'm writing an application that is supposed to show and hide the content of the main window stack panel based on the user choice. For example, the user clicks on the button that displays the list of the customers, then click on the button that displays the ordering form. The customers content should be hidden and the ordering form should be visible. Moreover, if there are contents with related information (like customers and their data) I want to be able to change the data in one window and it should automatically refresh the data in the other window when the user decides to open it. Is there a good way to do it in MVVM?
Thanks for any suggestions.
Because this question is so generic, the answer must be as well, and the answer is that this is exactly what MVVM is for - modeling data and binding it as needed. In fact, I would argue that a majority of MVVM examples you find online will be some flavor of an answer to your question, most likely using good ol' Northwind.
It sounds like you need to really take a good look at how you want to do your design before you jump in and start coding.
You might want to check out Prism (or as it is really named Composite Application Guidance). You can build really complex and modular designs with it.
You might be interested in the MVVM sample applications of the WPF Application Framework (WAF).
Writer: Shows how the Views (UserControls) can be switched (Edit mode; Print Preview mode).
BookLibrary: Shows how data modified in one View is automatically updated in other Views.
I'm designing data-oriented application in Silverlight 3 and I'm wondering if is it worth using new DataForm control. It looks really awesome on PowerPoint slides but I have no idea how it is in real life.
I need to achieve following behaviours:
group model's fields to areas, for instance separating groups using horizontal lines or naming group of fields,
place 2 or 3 input controls in exactly one row, for example: country-dropdown, zip textbox and city textbox,
multilingual validation errors,
a few readonly fields in edit mode,
posibility to hide fields in dataforms,
displying a helper button for showing modal popup window with dictionary/grid view.
I'd like to build it using Prism and RIA services.
Has anybody any experience to share?
I have tried using the DataForm in a couple of places in my current project. Spent several days tweaking the various properties and attributes on my classes and found that it never did quite work the way I wanted it to. The demos that are on the web look great but they don't have 'real world' scenarios and are incomplete. So, I wouldn't recomend the DataForm for complex scenarios.
My favourite feature of the DataForm control is that it works "out of the box". That is, you can plug one on your user interface, bind it to your data classes, and have it working with a minimal amount of code. Of course you need to further tune both the behavior and the appearance of the form (by using attributes on the data classes and/or properties on the form control itself), but for feasibility studies or for early usage testing it is usually enough (and very useful) to have it working quickly with the default behavior.
By the way this is a good resource to get started with the DataForm: http://www.silverlightshow.net/items/Creating-Rich-Data-Forms-in-Silverlight-3-Introduction.aspx