I have annoying appearance differences between Windows 10 devices and Windows 7 devices.
I am using WindowStyle="None" and DockPanel directly inside my Window element.
What I don't get is why there is still a border? Why are the borders on buttons, textboxes, comboboxes, etc. rounded?
It seems this is related to Aero. Is there a way I can stop my application from using Aero? I'm assuming there is another presentation framework related to Windows 10 but do not know what it is called to force it.
Would a BorderBrush be the easiest way to resolve this?
<Window x:Class="CBD.Presentation.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="clr-namespace:CBD.Presentation"
Title="CBD" Height="760" Width="944" WindowStartupLocation="CenterScreen"
WindowStyle="None" SizeChanged="Window_SizeChanged" MinWidth="944" MinHeight="760"
Icon="favicon.ico">
<DockPanel x:Name="Root_Window" Background="Black">
<!--Application stuff here -->
</DockPanel>
</Window>
Windows 7 display:
Windows 10 display:
Everything still functions properly but the way some textboxes and buttons are setup, parts of letters are missing.
I think both these is something a lot of people are going to stumble upon when they really start customizing the style of their applications. There's some well established shortcuts to both problems, such as using existing style/libraries for WPF:
There's a few common Window and style libraries I see:
MahApps.Metro is a great library I've used for a long time for getting clean windows and interfaces (especially with 'dark' themes some customers love).
Modern UI. Little personal experience, but it's similar in that it has more modern window designs, as well as a big style set. I've seen it used frequently.
Elysium. Again, not much experience, but seems active. I've not seen it used as much as the other two.
These, of course, include a lot of other Metro theming. There are other theme packs available, I've found the Material Design In XAML Toolkit great if a client want's a modern design (Also recognizable, being from Google).
It looks like you're making your style from scratch, but the above might still be useful for you to simply use for the windows. If you want to go at it yourself there's a lengthy discussion with lot's of answers here.
For the curved corners, as discussed in the comments, this is as a result of WPF's default behavior on different operating systems. It attempts to select a default style to blend in best with the current operating system. For most applications that just use the default theme, this doesn't often matter.
When you're styling everything yourself though, it really plays havoc with what you have manually configured, because some properties that work well with the theme you set things up on might be different - like the rounded corners.
There's two options.
Explicitly set all the properties, so it looks exactly how you want it. Doing this means that even if the 'base' theme changes, it will still look good. This is how those libraries above do things - they define a style completely. Problem is you will have to test it on the different themes manually and it's a bit of work.
Manually set the base theme. (Can also be used for testing in option 1!) You can override which theme your app uses manually rather than letting it use the default for the operating system in much the same way you apply other custom themes, or maybe your own:
<App.Resources>
<ResourceDictionary Source="/PresentationFramework.Aero, Version=3.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35,
ProcessorArchitecture=MSIL;component/themes/aero.normalcolor.xaml"/>
</App.Resources>
For some reason the above would not appear as code unless encased in quotes...
Related
I am writing code that is used in both WPF and Silverlight. In C# I can use "#if SILVERLIGHT" for conditional compilation, and it works.
In XAML, however, I must resort to use completely different XAML files, since some attributes are simply incompatible. XAML files are 99% a like, and keeping them in sync is a hassle.
I would like to convert them into a T4 template, so I can do things like:
<SomeControl <#=ClipsToBounds()#> />
Where ClipsToBounds() produces different text for WPF and Silverlight. The requirements are:
Intellisense while working on the XAML
Templates generated at build time
The project must be self contained and work on stock version of Visual Studio: installs of various SDKs and 3rd party editors are not
acceptable
Results of the template run should NOT be in source control. -
I found that I can change custom tool on a XAML file from MSBuild:Compile to TextTemplatingFileGenerator and I don't lose Intellisense. However, resulting templates are generated at design time. To have then generated at build time seems like a big pain.
Did anyone have successful experience with this kind of setup?
Only the generic user controls which have generic behaviors across the platforms can be placed in PCL , However,the best suggestion would be keeping separate xaml views for each platform .
Since nobody seems to have suggested a template based solution as desired, I'll share some experience of working with projects targetting both SL/WPF. Many people will suggest using two completely separate XAML files, a different view per-platform, and in many ways this is the "purist" thing to do. But if you want to eliminate duplication, and reduce the risk of your 2 targets drifting apart, I'd certainly suggest sharing the XAML files (with simple project links) can work acceptably well.
There are a few common incompatibilities:
Controls exist in both platforms in different namespaces - subclass your own version and refer to that.
Styles etc. need differ between platforms - include a common dictionary of resources, different per platform, and reference by key.
Controls are substantially different, or present in only 1 platform - introduce your own wrapper control (which may require substantial implementation in the 'missing' case).
Basic properties or functonality missing - can often hack something up with an attached behaviour (eg your ClipsToBounds example is found here).
This question already has answers here:
How to create custom window chrome in wpf?
(5 answers)
Closed 6 months ago.
We are developing a WPF application which uses Telerik's suite of controls and everything works and looks fine. Unfortunately, we recently needed to replace the base class of all our dialogs, changing RadWindow by the standard WPF window (reason is irrelevant to this discussion). In doing so, we ended up having an application which still looked pretty on all developer's computers (Windows 7 with Aero enabled) but was ugly when used in our client's environment (Terminal Services under Windows Server 2008 R2).
Telerik's RadWindow is a standard user control that mimicks a dialog's behaviour so styling it was not an issue. With WPF's Window though, I have a hard time changing its "border". What I mean by "border" here is both the title bar with the icon and the 3 standard buttons (Minimize, Maximize/Restore, Close) and the resize grip around the window.
How can I change the looks of these items:
Title bar color
3 standard buttons
Window's real border color
With round corners if possible.
Those are "non-client" areas and are controlled by Windows. Here is the MSDN docs on the subject (the pertinent info is at the top).
Basically, you set your Window's WindowStyle="None", then build your own window interface. (similar question on SO)
You need to set
WindowStyle="None", AllowsTransparency="True" and optionally ResizeMode="NoResize"
and then set the Style property of the window to your custom window style, where you design the appearance of the window (title bar, buttons, border) to anything you want and display the window contents in a ContentPresenter.
This seems to be a good article on how you can achieve this, but there are many other articles on the internet.
I found a more straight forward solution from #DK comment in this question, the solution is written by Alex and described here with source,
To make customized window:
download the sample project here
edit the generic.xaml file to customize the layout.
enjoy :).
Such statements as “you can't because only Windows can control the non-client area” are not quite true — Windows lets you specify the dimensions of the non–client area.
The downside is this is only possible by calling Windows' kernel methods, and since you're in .NET, which is not native code, you'll need P/Invoke. (Remember, the whole of the Windows Form UI and console application I/O methods are offered as wrappers that make system calls under the hood.) Hence, as documented in MSDN, it is completely possible to use P/Invoke to access those methods that are needed to set up the non–client area.
Update: Simpler than ever!
As of .NET 4.5, you can just use the WindowChrome class to adjust the non-client area. Get started here and here, a guide to changing the window border dimensions. By setting it to 0, you'll be able to implement your custom window border in place of the system's one.
I suggest you to start from an existing solution and customize it to fit your needs, that's better than starting from scratch!
I was looking for the same thing and I fall on this open source solution, I hope it will help.
I'm writing some extension modules for a WPF Composite application supplied by another vendor. The application is themed, and gives users the option to select from a number of themes which will change the appearance of the entire applications, including any custom modules that register themselves with the theme manager appropriately.
I really want my custom extensions to look like an integrated component, so I'm trying to use only styles defined as resources within the main application. As I'm still learning the nuances of XAML, I'm styling more by trial and error.
I'm wondering if there's a way of 'discovering' what styles are available in a different assembly. Here is an example of what I'm currently doing.
<Window.Resources>
<ResourceDictionary>
<ResourceDictionary.MergedDictionaries>
<common:DesignTimeResourceDictionary Source="/Vendor.Desktop.WPFCommon;component/themes/generic.xaml" />
</ResourceDictionary.MergedDictionaries>
</ResourceDictionary>
</Window.Resources>
<Border
Background="{DynamicResource LightGradientBackgroundBrush}"
Margin="0"
>
The LightGradientBackgroundBrush is defined in the vendors assemblies. By including the above ResourceDictionary, the style is present during design time, and the brush isn't underlined in the XAML editor.
Can I find what other styles are defined? I'm only aware of that style because it was mentioned in passing in a sample provided by the vendor.
Edit:
I'm aware of a BAML add-in for reflector, but it doesn't work with reflector 7 unless it has been recompiled/patched. Someone has already done that here though.
I was hoping there was a better solution though. Intellisense for styles would be great.
There used to be a Reflector add-in for viewing BAML resources that worked well for that. But I haven't used Reflector in a while since Redgate crashed the party. It may not work with the current version.
You know where your resource dictionary is so you should be able to load it up in code and enumerate over the available resources. This will at least give you an idea of what's available.
See this link: http://blogs.claritycon.com/leeroth/2009/05/20/load-xaml-resource-dictionaries-at-runtime/
Enumerate over the Keys property and use the item property to access the resources. You can get as detailed as you want, but at the very least you should be able to spit out the resource names.
My understanding of the difference between a WPF theme and a WPF skin is the following:
A WPF skin is a set of resources loaded by an application.
A WPF theme is a set of resources handled by the OS.
To load a skin, I can just call Application.Current.Resources.MergedDictionaries.Add (mySkin);
However, I don't see any way to load a theme.
Is this documented or available?
Should I access the System.Windows.SystemResources internal class?
You can load them as a ResourceDictionary:
<Window
x:Class=”TestProject.Window1?
xmlns=”http://schemas.microsoft.com/winfx/2006/xaml/presentation”
xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml”>
<Window.Resources>
<ResourceDictionary
Source=”/presentationframework.aero;component/themes/aero.normalcolor.xaml” />
</Window.Resources>
</Window>
Note: You would need to have a reference to the PresentationFramework.Aero.dll.
There's quite a subtle difference between Skins and Themes, and the reason why you're having problems with what you're trying to do might stem from this:
In WPF, a theming and skinning takes
on slight variations to their
meanings. Theming refers to
controlling the look and consistency
of an application UI to match the
operating system. For example, a WPF
application can be themed for the
Windows Aero theme or the Windows
Classic Theme. Skinning refers to
changing the application's appearance.
In other words, applying or letting
the user pick a skin to change the
look and feel of the application.
Robby Ingrebertsen, while working on
the WPF team, simplifies it as
follows:
Around here, we generally say that "theming" refers to the system theme
and "skinning" refers to changes to a specific app. This has helped to
clarify our internal communication
From here
So essentially, if you want your app to look like one of the Windows themes,ie the current windows theme - you don't have to set any styles in your app and it'll chose a pre-defined XAML skin that resembles it automatically. But, if you want to style your application, you make a skin for the app as you're doing.
As far as loading the Windows themes, this answer might help
(Answering my own question)
The way to load a resource dictionary as a theme is to add it to the list of merged dictionaries of the generic.xaml resource dictionary.
I've been developing with WPF for many months now. It's a great framework and I'm able to do fancy, elegant stuff that would have been a lot more difficult with WinForms.
However, I do have the feeling that for normal "line of business" type of applications without any special UI requirements, it still takes me longer to code the UI in XAML than it did to drag-and-drop it in WinForms.
For example, in WinForms, I would just drop an additional label and an additional textbox on the form and arrange everything (using the helper lines) until it looks nice. In WPF, I'd start by factoring out the properties of the existing label and textbox into a style, so I can reuse them; think about the most suitable layout element, maybe refactor some dockpanels/stackpanels into a grid (or vice versa); try different values for the margins etc. Although I have a lot of experience in WPF, it still takes a long time.
I know that I could just forget about "clean XAML" and use the GUI designer in Visual Studio 2008 (which just absolutely positions everything inside a huge grid), but I fear that I would lose a lot of the advantages that XAML offers by doing that.
Have you experienced something similar? If yes, what did you do to speed up everyday WPF development?
What I do to speed up everyday WPF development:
Ignore look and feel for as long as I can. Ideally, tweaking alignments and margins and defining styles is the very last thing I do.
Use the DockPanel before using a Grid, and a Grid before using a StackPanel.
When using the Grid, star-size everything. I'll come back and fix this later, but during prototyping, having a clear idea of how many rows and columns the Grid actually has is enormously helpful.
Prototype in Kaxaml, finish in Expression Blend, test in Visual Studio. Figuring out a methodology for this has taken a lot of time, and it's still very much a work in progress. But Kaxaml is great for quickly seeing how a XAML prototype will behave, and Blend is great for working out the visuals and encapsulating things into user controls and styles.
When using Blend, don't create layouts in the artboard, create them in the object outline. When I'm first developing a WPF UI, the hierarchy of objects is a hundred times more important than how it looks on the screen. I'm still learning to do this, and it seems possible that once I get good enough at it I won't need to prototype in Kaxaml anymore.
Work on the smallest thing possible. This requires a lot of discipline. I've got a nice big complex XAML file, and I decide that I need to edit the template of a control The first thing to do is to create a tiny XAML file with that control in it, and edit the control template there. The temptation to work like this in situ is strong, as editing the control template is only a right-click away. Don't do it.
Don't even think about whether or not I should develop a view model for my tiny little one-off application. Yes, I should.
Learn Blend. Really, really learn it. Learn what all of the tiny icons that surround the selected object mean, and pay attention to them. (Here's a shortcut: I didn't set margins on that thing, but Blend did. That's the answer to maybe 30% of my "what the hell is Blend doing now?" questions.) Use the Blend UI even if I know it would be faster to edit the XAML by hand. This is again a matter of discipline, resisting the temptation to get it done now so that I can improve my ability to get more of it done later.
That's kinda like saying "Sliced apples are easy to make, but apple pie tastes better. How can I make apple pie as easily as I can slice apples?" Well, you can make it easier by using pre-made pie crusts or buying pre-sliced apples, but it will never be quite as easy, because lets face it, you're making something that's a lot more complex and potentially tastier.
It sounds like making styles holds you up. You could get off to a much quicker start if you just imported the same styles with every project. Usually I fly right along once I have all of my styles made.
Otherwise, the only way to make it as easy as the drag-and-drop WinForms designer is to use the drag-and-drop WPF designer.
I've been using WPF for a couple of years now - for optimal speed, I disable the design-view, use snippets, intellisense intensively (and of course ReSharper).
And then I make things simple - I have descided to use standard layout for almost everything - ie. main-screen bit -> DockPanel, ToolBar docked top -> snippet.
Popup screen -> DockPanel, ToolBar docked top, custom Persistent section docked bottom (Save and Cancel buttons) - properties of the viewmodel -> UserControl with grid, labels and properties.
For styling - first do that when I have at least 3 screens for each type - create resource dictionaries for each type. Define common stylings - Header textblock etc. Import ResourceDictionary in each screen and apply styles.
Apply coloring, margins, padding etc. in App.Xaml with non-keyed styles.
I can't think of a faster way. At least for me, I don't really need to think while doing it this way (so, I can use my brainpower later for the complex stuff) - and it gives a consistent "LOB-look" that is relatively easy to style, theme and change later on. It's basically a matter of typing.
My biggest challenge at the moment is that I'm constantly thinking of ways that the UI could be composed dynamically with data templates, which can often get in the way of simpler solutions when the extra flexibility is not required. Other than that, I've become faster now that I'm getting used to the different containers and their quirks. It's such a dramatically different technology that it's going to take time before I develop the appropriate mental tool set for my day-to-day UI tasks, especially since I still need to use WinForms regularly. I figure it's just a matter of time, however, before I have standard patterns in mind that I can deploy quickly and easily.
The advice about VS2010 is very good; its visual designer is actually useful, compared to VS2008's XAML designer, which was less than useless.
Microsoft's PR machine pushes the "Model-View-ViewModel" pattern extensively for line-of-business apps, to the point where they actually recommend things that can waste your time.
Do not spend hours trying to shoe-horn everything into XAML, unless your company or client has procedures which require it. If you can code it faster in VB or C#, and the code is still maintainable, testable, and readable, do it.
Do not become an MVVM purist; not even Microsoft has figured out the appropriate balance for this pattern, and even with the Silverlight 4 stuff, they haven't come up with a good set of development tools or best practices for the pattern, even though it's now been almost five years since it was first proposed; there are still very valid reasons to abandon ICommand and INotifyPropertyChanged in favor of just calling a method on your ViewModel from the code-behind. Also, no non-Microsoft WPF/Silverlight expert I've listened to in the past few months has failed to say, "I'm not sure about MVVM yet, I'm not a purist."
Find a balance and use XAML for what works for you, and C# or VB for what works for you. MS devs on their blogs are fond of calling XAML "markup", and C# or VB is "code, unfortunately". Well, if you're typing it in or laying it out, it's all code, and the truth is that all that XAML gets interpreted and then turned into C# or VB in files you can't see or readily edit, before it's compiled down. (For example, Application.g.vb is generated from Application.xaml as a partial class.)
There are XAML constructs like animations and storyboards which take many lines to lay out in XAML, but in the procedural languages might only take one or two lines of code and actually be easier to read, especially if the animation responds to an event under only certain conditions. Do what works best.
Also, if you're coding along and keep hitting run-time exceptions which make no sense, take a step back, find an alternate answer that gets you functioning, and implement it. Most XAML errors can't be caught by Intellisense or the compiler. It's possible to bang your head for weeks against a XAML problem, that can be coded in C# or VB with early binding in a comparatively much shorter time.
In short, relax and code to your own best practices, using the VS2010 tools, and you should be able to pick up speed.
If you use VS2010 I think the visual designer for the XAML is better now and I think brings the development time more in line with classic winforms development.
If you still need to target .NET 3.5 you can by setting the solution to compile to 3.5 instead of 4.0. This might be a good option for you if you aren't using VS2010 yet.
I feel your pain... Everytime we add a new field into the database, another TextBox/ComboBox has to be made on the form. I've found that using Expression Blend allows me to be much quicker at laying out the form. The downside is that using Blend tends to create more xaml than writing it by hand, so I usually end up cleaning up the xaml a bit.
In the end, Blend is a much better designer than Visual Studio (2010 included), so it's much quicker to do your design work in Blend, and development work in VS. (just my two cents)