I am trying to set the document of FlowDocumentReader at design-time but cannot figure out how to do it in a pure declarative way. There is no design-time attribute for Document and using DataContext does not work (for obvious reasons I think). What is the best way to this:
in a declarative way (preferred)
in a mostly declarative way with some helper code (less preferred)
using only code (least preferred)
The declarative design-time is important since we are using sketchflow to mockup an application screen where the user can see the (paragraph and character) styles and navigate through the document using these styles.
All suggestions are welcome.
Thanks, Marc
Related
I am trying to understand the use of XAML instead using it as markup in creating WPF and silverlight applications. Where else could i use XAML. Please provider all the possible uses of XAML.
Could XAML be used as regular XML to provider mapping and related stuff?
Please provider some links where i could learn about XAML.
Thanks.
This writeup can be helpful: http://www.davidpoll.com/2010/07/25/to-xaml-with-love-an-experiment-with-xaml-serialization-in-silverlight/. This article describes a way on how XAML can be used as a serialization format not just for a user-interface, but also for other CLR objects.
XAML is used as the serialization mechanism for workflows in Windows Workflow Foundation (WF), see for example http://www.codeproject.com/KB/WF/XAML_WF.aspx
XAML's a fairly efficient XML serialization format with hooks for namespaces and markup extensions. You don't have to use it purely for WPF applications; as long as the types you're serializing have parameterless constructors you can represent just about any .NET reference type in XAML.
If you're not using markup extensions, it's not really a huge leap past ordinary XML serialization. But the incremental improvements that it offers are useful enough, and the fact that it's a format supported by VS and WPF and Blend certainly doesn't hurt.
As far as I know, XAML is only used in WPF and Silverlight, isn't it?
Thanks.
No, it is also used in Windows Workflow Foundation:
Using Workflow Markup
XAML is also the basis for XPS.
It is also used in Office 2007+ *x formats
You can use it for whatever you like (beginning with .NET 4.0 if I'm not mistaken, didn't try it in 3.5).
However, if you do so, please also use the other good things .NET has to offer, such as "INotifyPropertyChanged" and dependency properties. Otherwise whatever you create will be a less - than - optimal solution.
There is a huge mistake I often see people make when they say, "XAML is UI markup." It's not. You can have XAML with no UI whatsoever. XAML is, in essence, an XML object graph. It is markup for creating classes. It provides the parser with instructions on how to generate instances of types and set properties on those types. This is extremely useful for creating UI in WPF and Silverlight but can also extend to sample data, view models, and other constructs. As mentioned here, it is also used in Workflow and other areas.
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
In Windows Forms, it was useful at times to have one window that inherited from another window. But in WPF, this is not allowed. Why is there no visual inheritance for WPF windows?
The reason WPF does not support visual inheritance is due to the fact that the form design is achieved via markup (.xaml) as opposed to winforms which use code-behind to produce the layout. Code-behind is extensible and markup is not. The same goes for web forms. Master pages in asp.net offer a quasi visual inheritance. So it is a trade off, markup offers the benefit of a clear separation of layout and data whereas code-behind offer visual extensibility. It is a bit of a shame since visual extensibility works so well in creating consistency in the GUI as well as very rapid development. Well, it seems flare is more in demand than functionality. WPF is just ok...
WPF is deliberately very, very different from Windows Forms. The composability model is not based on Windows, but on classes like Dependency Object, Visual, UIElement. You can also dramatically modify the behavior of existing things using control templates, styles, data binding and other techniques.
I encourage you to experiment! WPF is very easy to prototype with
In WPF, a large effort was made to separate visual from logical. Because of this, there is a LARGE amount of freedom to make the UI look however you want. All of the controls, including windows, are "lookless". You can provide your own look via templates and styles. A default visual style has been provided that makes everything look like you would expect, but you don't have to use it.
I'm writing a fairly big interface using Silverlight. As I progress, the xaml file is getting fairly big and is becoming proportionally uglier.
Questions
Are there any resources out there to make the xaml more readable? For example, how would I display the order of attributes (e.g. height and Width first) so that it looks the most tidy?
Another issue is that there are multiple ways to implement an interface with grids and stack panels. Is there a preferred approach when using one or the other?
I am looking for advice and links to other resources that can be used as examples.
If you have lots of complex XAML, you could try to break it down into several UserControls to make it more modular and have less XAML in each file.
Here is a tutorial
http://silverlight.net/learn/tutorials/usercontrols.aspx
And here is a video
http://silverlight.net/learn/learnvideo.aspx?video=52036
This may be the same as the XAML best practices question, where the recommendation was to take a look at http://dotnet.org.za/rudi/archive/2009/01/13/xaml-guidelines-released.aspx
SilverLight like any other UI language has the size complexity problem
Much has been written about this problem in the HTML world, and the same rules apply
Use a testable pattern like MVP, MVC etc - There are test frameowrks for SilverLight
Keeping resource in separate files - A page layout should just be layout. Style, themes etc are shared resources in general
Use custom controls - try to avoid using the generic built in controls as they come, wrap them up in a custom control with all your default properties and handlers etc. When you then use this control on a page layout there is less attribute baggage to go with it
I prefer stackpanels over grids for their simplicity - It's a bit like the HTML worlds table vs .css layouts war
Have a look at other peoples SilverLight efforts with SilverLight Spy, and you might feel better about your own :-)
Check out the series on best practices for Silverlight on:
Silverlight 2 Best Practices - 4 articles
The author has 4 articles on this.