I'am learning wpf. As a part of learning I'm converting a winforms application into a wpf application using mvvm.
In winforms I just dragged and droped. After that I aligned based on my requirement.
But in WPF when i drag and drop a default grid is wrapping the components and I'm facing great difficulty in aligning the components.
On learning the tutorials on wpf https://www.tutorialspoint.com/wpf/wpf_layouts.htm
I tried to work with but I don't know which is suitable for my UI.
I want to create UI in wpf as below winform
I have used grid and stackpanel but I have issue with alignment. In grid I have issue with adding new elements in the existing row. In stackpanel I face issue with spacing between the components and aligning the compnent.
Can anyone help me on which panel to use for the above kind of UI.
In general you don't use editors for WPF, you edit the layout XAML by hand and use the visualizer as a guide to show whether or not you've done it right. The Visual Studio editor does let you do things like basic layout, but as soon as you start using ControlTemplates/DataTemplates/Behaviours etc you'll quickly find that it's useless (and believe me, that moment will come much sooner than you think). If you really want to use a graphical editor then Microsoft Blend is your best bet, but even that is generally designed for non-programmers. In fact, in the 10+ years I've been a professional WPF contractor I've yet to encounter a single company that actually uses Blend...or indeed any other GUI-driven XAML editor...for their product development.
I read that WPF uses DirectX under the hood to perform its rendering, that it doesn't rely on the dinosaurian libraries that WinForms uses to render controls.
So I made my Presentation layer with WPF and it looks the way it should under Win8.
Then I deployed the project to Windows Server 2003... to find out that my nice little custom message box looks awfully WinForms-like and somewhat clunky; the button controls are VERY similar to the WinForms ones, the expander control is no longer shown as a circled ^ arrow and looks like it was drawn in 1998 (picture the ^ arrow on an ugly square flat button that pops up when your mouse hovers over it).
From the Pro WPF in C# 2010 Bible:
Part of the promise of WPF is that you don't need to worry about the details and idiosyncrasies of specific hardware. WPF is intelligent enough to use hardware optimizations where possible, but it has a software fallback for everything. So if you run a WPF application on a computer with a legacy video card, the interface will still appear the way you designed it.
So, is this a lie? To me it is, because it doesn't appear the way I designed it.
If not, then why/how doesn't the thing render identically regardless of the machine that's running it? Is the software fallback somehow designed to mimick Win32/GDI rendering? Is there a way to get my little custom message box to look identical on Win8 and WinServer2K3?
That has NOTHING to do with DirectX / Rendering / video card / any of that.
and EVERYTHING to do with WPF taking the DEFAULT appearance of ALL UI Elements from the Windows Theme.
If you don't want this behavior, you'll have to provide Styles and Templates for ALL UI element types, or otherwise find a way to include PresentationFramework.Aero.dll in your application and use that as the default theme library.
Take a look at this answer
I have seen packages like MahApps (http://mahapps.com/MahApps.Metro/) which will allow WPF programs to have the look and feel of Metro.
I've also seen some pretty good looking Silverlight programs created with that Metro theme in mind. For example, when you click a button a panel will slide/transition out over the time span of about a quarter of a second (I don't mean just a simple fade in, I mean the panel physically moving across the screen until it is at full size). My understanding is that this is achieved with storyboards.
My question is whether it is possible in a WPF application to do these sort of transition / visual effects? Or is it something that is strictly in the realm of Silverlight?
Thanks
There is nothing to prevent you from doing these transitions in WPF.
Which technology (WPF or Winforms) should be used if UI supposed to be highly customizable like controls layout/design could be change by user and such sort of UI customization.
Kindly mention best practices along to achieve that...
I just recently developed a designer in both WinForms (company req) and WPF (to see how much better it was). WPF has a definate edge, especially when it comes to nicer looking controls and control transparency.
This was my first actual WPF project, other than just messing around, so I was learning as I went. I found this series on creating a diagram designer very helpful. I didn't really do the same things that this article talks about, but more of a hybrid between that and my WinForms app.
I have to admit that the UI functionality was up and running much faster in the WPF version than with the WinForms version.
WPF I have found the easiest to create controls on a fly. Because I can just attach them as child controls to the parent, and the Grids, Dock Panels, just make life easier.
I found WinForms to be clunky to always work with. However I come from a Web background and Xaml makes sense to me.
WPF controls are design and lookless. That means you have a default view of them, but everything detail of a WPF control can be overridden. It's almost akin to using CSS. In the WPF world, you do not create custom controls like you do in WinForms. The main thing in WPF world is "styling" controls and defining a style for them. It just happens that the style also controls the layout and the form of the controls.
WPF is FAR superior for designing and style of UI. Check out these two top WPF companies and tell me if this stuff is easy to do in WinForms:
Cynergy Systems: http://www.cynergysystems.com/
Thirteen23: http://www.thirteen23.com/
I've been doing WPF applications with the MVVM pattern using Visual Studio, coding C# and XAML mostly by hand.
Now I've gotten up to speed with Expression Blend so that I can click together WPF applications quickly just using the GUI, which is very nice, much more control of the layout than fiddling around with all the XAML elements 80% of your time.
But it seems that my applications in Expression Blend are simpler and necessarily coupled, using events that are handled in the code behind, etc.
I find it hard to imagine how I would go from this simpler approach of Expression Blend to a decoupled MVVM application with Views, ViewModels, routed events and commands, etc. other than to just take my whole project into Visual Studio and rearrange it to the point that I couldn't really edit it visually anymore in Blend, but would be back to using Blend to create little pieces of XAML that I paste into Visual Studio.
For those of you who are working with more complex applications with Expression Blend, what are your strategies for keeping your projects decoupled in an MVVM way, yet at the same time structured "in the Expression Blend way" (where you can still see and edit whole parts of your application in a way that makes sense visually) so that you can continue to edit them in the Blend GUI as they scale?
I've been using Blend first and foremost as a rapid-prototyping tool. For this purpose, I really like it. In particular, I find it very helpful when I'm not sure how to set things up to get the layout/behavior that I want.
I rarely edit my main project files directly in Blend. I find it creates markup that is unnecessarily complex or verbose. Also, as I become more familiar with WPF/XAML, I find myself using Blend less and less.
I have been using Blend for the UI of my projects since version 1. Being that my goal is to fully integrate the designer to the project, I have plowed through whatever gets in the way of this goal. While not being aware of MVVM for some time now, I naturally arrived at the same conclusion, and have been making ViewModels without knowing there was a pattern for them. Now with the help of others that are working towards MVVM, it's getting better all the time. I have now developed 3 applications with rich UI and functionality where all the UI was done in Blend.
Read Josh Smith's MSDN article, look at Jason Dolinger's work, and Karl Shifflett's work to mention just a few.
Look closely at using ICommand, INotifyPropertyChanged, the ObservableCollections.
Also, look for how you can manipulate controls from your ViewModel. As an example, there is ICollectionView. Assume that you have a list of animals, and you have a set of types that you want to filter them by (birds, mammals, etc.)
By using ICommand and ICollectionView, you could expose enough control where a designer could construct a listbox to show the animals, and a menu to show the filter list. There is enough functionality in ICollectionView to know what the current selection is, and if you had ICommand-based commands for "SortByBird", "SortByMammal", etc then when the designer made the menu, it (assuming the window's context was your ViewModel for this window) would supply the designer with the proper options to bind to.
I am currently working with another team at my company explaining how my projects have been set up, and they are responding positively to the new role of the designer using Blend.
I have not been able to successfully use Blend end to end for that.
I find in the general case, it's faster to edit xaml by hand in VS (exception would include anything with non-standard brushes for example). Blend is very click-happy, and it's not really fast to top it off.
Another area where Blend is really useful is creating styles/templates from existing controls.
Other than that, I'm not sold yet. Its capabilities drop when using code-instantiated datacontexts so it's no help there, and it tends to generate useless markup, static sizes and such, which I really don't like.
Blend is great for giving you an idea about how things can be done, but the xaml it makes is terrible and tightly coupled. As you learn the xaml side of things better you'll find it's much faster to just write the xaml than use Blend. Until you get to that point you can make your changes in Blend but then you should refactor the xaml it creates to make it less tightly coupled and take out the extraneous UI elements.
I'm a little late to this party, but hope that someone can still respond. I've yet to find a search result that outlines the process for drawing a line between the designer and programmer. The first part of it is MVVM so there isn't any coupling between the GUI and the underlying "business logic", and I'm working hard on learning that right now. The other part that I haven't seen anyone write about is, how do you actually go about designing a project in Blend so that the developer can basically give you a GUI DLL of sorts, and then your application's GUI magically changes?
Here's what I'm looking for -- the developer writes his code as usual, and also writes a very basic GUI that proves everything works as expected. Meanwhile, the designer is creating his cool little GUI with all of the usability features people have come to expect. Now, the developer can run his application with his GUI, but then can also switch to the designer's GUI on the fly.
I guess if it can't be done on the fly, does that mean in the ideal case that the developer would have his VS solution include the XAML from the Blend solution? Then in App.xaml just reference a different start file?