I'm still getting to grips with WPF: can anyone tell me if we should still use IPersistComponentSettings with WPF and if not, what is the new mechanism?
From the book Programming WPF:
The preferred setting mechanism for WPF applications is the one provided by .NET and VS: the ApplicationSettingBase class from the System.Configuration namespace with the built-in designer.
There is an example of inheriting your own settings class from ApplicationSettingBase provided in that link. You can also check out other ideas for saving settings, demonstrated in similar questions here and here.
Related
I'm new to catel and mvvm. I 've successfully built a sample application the "catel" way and I like all the added features which I do need (thank you for the great tutorials). I've successfully run a sample app using typical mvvm and a 3rd party control printing reports. When I tried to use the 3rd party control in the catel application I had issues making it work, even with the information provided in catels' documentation. Even if I do manage it to work, I don't want to make custom base classes to add new controls, because most of my controls are special (3D). So, my question: can I use all of the catel features, including model and viewmodel capabilities, but use external windows and controls with the typical manual binding procedure? Do I need to know of any special concerns?
I learn catel since 2 weeks too, welcome into the Catel World :)
So, you can create custom window base class with IDataWindow and your window inherit Catel features. Need more coding but not a lot !
I suggest you to consult the excellent documentation here for Custom Window and here for Custom Control
Hope it's help !
Dams
Why is there a difference in the way the Application object is created in WinForms and WPF?
-> In WinForms we never created the Application object. It was always available (I believe it was Singleton pattern). In WPF, although hidden in App.g.cs we need to instantiate one.
-> In WinForms it was a sealed class, but in WPF the way to go is to inherit it.
Is this done:
to be able to define the application in Xaml (App.xaml)
due to introduction xbap/navigation projects?
What benefits does it really provide?
I don't know that the design decision is entirely motivated by the desire to be able to define the Application object in XAML. But that's reason enough, it seems to me.
I'm currently working on a brownfield application, it's written with winforms,
as a preparation to use WPF in a later version, out team plans to at least use the
MVVM/Presentation model, and bind it against winforms...
I've explored the subject, including the posts in this site (which i love very much),
when boiled down, the main advantage of wpf are :
binding controls to properties in xaml.
binding commands to command objects in the viewmodel.
the first feature is easy to implement (in code), or with a generic control binder, which binds all the controls in the form.
the second feature is a little harder to implement, but if you inherit from all your controls and add a command property (which is triggered by an internal event such as click), which is binded to a command instance in the ViewModel.
The challenges I'm currently aware of are :
implementing a commandmanager, (which will trigger the CanInvoke method of the commands as necessery.
winforms only supports one level of databinding : datasource, datamember, wpf is much more flexible.
am i missing any other major features that winforms lacks in comparison with wpf, when attempting to implement this design pattern?
i sure many of you will recommend some sort of MVP pattern, but MVVM/Presentation model is the way to go for me, because I'll want future WPF support.
Thanks in advance,
Erik.
Please take a look at Update Controls .NET. It is an open-source library for Winforms, WPF, and Silverlight that keeps controls up to date as data changes. You can start using it now for Winforms, and then transition over to WPF without changing your Data Model or View Model code.
Unfortunately, it does not solve the Winforms command binding problem. Your button click events will not port from Winforms to WPF. But it does take care of the data binding problem.
You might find the WAF Windows Forms Adapter interesting. It shows how to apply the Model-View-ViewModel (MVVM) Pattern in a Windows Forms application. The Adapter implementation provides a solution for the missing Command support in Windows Forms.
What would be a good aproach to localize a MVVM based WPF allication that can change its language at runtime? Of course I could create a string property in the ViewModel for each and every string that is displayed somewhere in the View but that seems rather tedious to me. Is there a common approach/best practice for this?
Here's an excellent article about WPF localization. It deals with the Microsoft-supported localization technique, and a few alternative ones
I wouldn't recommend the "official" solution for localization... it's really a pain to use, it modifies you XAML (adds x:Uid attributes to every element that can be localized), and there are no good tools from MS to make it an easy solution. Good old resx localization is much easier to use, and integrates quite well with WPF with just a few tricks (namely, markup extensions and/or attached properties). Also, you can easily change the interface language at runtime thanks to the binding system.
WPF has a lot of support for localization. Perhaps you can leverage that? Unfortunately I think that changing the user interface language at run-time is somewhat difficult and you probably need to come up with your own scheme.
Also, as the view-model is UI agnostic I don't think storing user interface strings in the view-model is a good solution. These belong to the view.
Instead of having user interface strings in your view model, you can store them in the assembly's resources and access them directly from XAML, using x:Static:
<TextBlock Text="{x:Static props:Resources.MyLabel}"/>
The props namespace should refer to your assembly's Properties namespace:
xmlns:props="clr-namespace:My.Assembly.Properties"
You can use a Custom Markup Extension to lookup localized values and update them when the UI Culture changes.
Here's an example of how this might work:
<Label x:Name="lblResxHelloWorldMarkupExtension1Value"
Content="{res:Res Id=HelloWorld,Default=Hello#}"
Margin="{res:Res Id=HelloWorldMargin,Default=10}"
Width="{res:Res Id=HelloWorldWidth,
ResourceSet=WpfClickOnce.MyFormRes, Default=50}" />
This example is taken from the excellent WPF Localization Guidance authored by Rick Strahl and Michele Leroux Bustamante here: http://wpflocalization.codeplex.com/. Download the guide from this site where this technique is described in detail in document form and with a sample application.
Another nice advantage of this approach is that it works in the designer.
If you are almost interested on this topic you can have a look at my library that I'm developing on codeplex.
LocalizationLibrary: http://localizationlibrary.codeplex.com/
Here's a couple of articles that could be of interest:
Localizing WPF Applications using Locbaml
WPF Runtime Localization
Simple WPF Localization
Based on the sample from http://msdn.microsoft.com/en-us/library/ms771725.aspx
which is for WPF. I wanted same sample for silverlight as my requirements are same. but i get
"AG_E_PARSER_BAD_PROPERTY_VALUE" pointing to
in my XAML (FYI: xmlns:dat="clr-namespace:System.Windows.Data;assembly=System.Windows.Data").
Please help me in achieving the same.
There is not a direct 1-to-1 match between WPF and Silverlight nor the XAML used in those technologies. The error you are getting implies that the XAML is trying to set a property that either doesn't exist or doesn't support the value being applied to it.
To track this down, you'll need to look into the differences between the version of Silverlight you are using and the version of WPF that you are porting from. Just googling or binging gives quite a few links regarding this.