im looking for some tips and hints how i can build up my Application in a good way.
So here are some informations: I have at the moment the Mainwindow designed with a grid which holds 4 frames. its looking like this.
At the top is a menu which let you select the different Pages. I have for the main area about 8 pages for e.g. a settings page and 4 content pages. The Sidebar displays some additional informations which can be choosen by the user and the bottom shows only a page when 1 of the content pages are opened.
So my content pages have ViewModels behind to fill them and im trying to use commands in the near future when im understand all features of them ;). So im trying to use the MVVM way, but im very new at this.
I don't really need a navigation menu like it is given from navigation windows.
So is it the best way for an application like that to use Frames or are there any better solutions?
Frames support the built-in navigation infrastructure of WPF so they're a good choice if you plan to use that. It does have some problems (at least some people think so, including me) but for simple/small applications it will do just fine. Of course they'll also work if you want to roll your own light-weight navigation system, like I usually do. I generally navigate by sending instances of ViewModels around and setting them as the contents of windows or content controls, and letting DataTemplates 'dress' them up as they are defined in the views. For larger projects I'd always recommend one of the awesome frameworks which include navigation systems like Prism or Magellan.
Basically it all depends on your requirements; there are a lot of ways to get it right. It's good that you're trying to use MVVM, try to stick with that and it will generally automatically guide you in a good direction.
I'd suggest using a docking library like AvalonDock to spice your application up a bit... however I have a bitter experience with it as it's not MVVM-friendly. I recently spent the better part of a week wrestling with it to make it usable enough in a MVVM scenario and I'm not sure it can ever be done. There may be other libraries that handle things better, but (full-featured, like in Visual Studio) docking is a complicated matter so maybe don't go there. Sorry, I probably felt the need to vent after the AvalonDock frustrations.
Related
This is the first Xamarin.Forms app I try to create, so please bear with me.
I'm learning about Xamarin.Forms, and I'm creating my first app (with a map) that will run in the android emulator. I've already added the map, so life is good.
I also understand that, unlike asp.net webforms or Windows forms, I cannot drag & drop controls to the form. I also don't know what the available controls for each platform look like.
With that said, I would like to add the following control to my app. I have no idea how it's called, but it's sort of a panel on the bottom half of the screen. This panel will include a list (much like a gridview).
I saw this Xamarin page with a list of standard controls, but I don't know how to identify them. Even worse, I don't know what to search for in the web.
I would like to know where I can find information on adding that control to a form and populating it with data (like an asp.net gridview)
Something like that is usually rendered using an ActionSheet
Unfortunately there isn't such a control. On iOS it is done by partially covering the screen while presenting the TableViewController. You can't do something like that on Xamarin.Forms. You can do that only on native projects.
There might be some plugins that may do some of that work for you but I don't think any of them fits your request, but you can try how far you can get with this one: https://github.com/rotorgames/Rg.Plugins.Popup
Please note that Xamarin.Forms don't cover all native controls and especially not all properties of those controls. And while you may extend their reach in various ways if you are after copying everything you see in some app it is better to think of some other technology.
Also of note, Android doesn't support everything that iOS supports, so if you see something on iOS screen (like above) it may not be supported on Android, no matter what technology you use you will have to build a very custom solution, which probably isn't part of your first app.
I am writing a UWP app which needs to show milestones against multiple, grouped tasks along a timeline of a video. Basically showing when a task occurred in the timeline. Image below of a crappy excel mock up of what I am talking about.
I have searched and can find some charting option but they are for WPF, javascript or .Net Framework.
Was thinking I could have a go at one myself using a grid as a base and I'm OK on this front for the moment, I am wanting to know if anyone knows of any suitable timeline controls for UWP or can think of another way to visualise this sort of data using available controls.
There are a number of options for UWP if you wanting to just xaml output a DataGrid the only free one I've seen is this
https://github.com/RSuter/MyToolkit
However if your willing to fork some cash there are lots of options. The obvious solution would be which is free for non-commercial use so you can give it a test.
http://www.telerik.com/universal-windows-platform-ui which has a great datagrid
the concept would be removing the first column and adding a new one at the end in a poll
The other option which I thought about mentioning before is https://www.syncfusion.com/ they have a graph library for UWP I have never used there product so I can't really say much about it except I believe they do have a timeline graph.
This is quite old now but I have just had the same issue. After a day of research I have discovered the SyncFusion CellGrid does this perfectly.
https://help.syncfusion.com/uwp/cellgrid/getting-started
I'm about to start porting my WP8.1 app to W10, and looks like I'll have to make it a Universal Windows App. Now, I'm fine as for the back-end code, as I'll be able to reuse 90% of my classes (Models, ViewModels, and most of my helper classes, extension methods and converters).
The problem is for the UI: I understand I'll have to design the app for different screens and aspect rations, and I don't know how to actually implement that in code.
I mean, as for the UI scaling, I know I can use the VisualStateManager and AdaptiveTriggers to manually set the properties of the UI elements I want to adapt on any screen resolution, or I can use some converters, and that's fine.
Whan I mean is: what's the best method to have the whole UI adapt to different resolutions?
This is an example:
As you can see: the whole navigation pattern changes along the UI when on different screens. On phones, we have the contact page that covers the whole UI, while on tablets and PCs we have the contact page that's just a fraction of the UI, and the pivot pages are moved into another panel on the right. Also, many of the UI elements are completely rearranged.
And of course, some view-level back-end code will change as well.
Now, I'm wondering what's the best approach to do this whole thing.
Should I:
• Have a single XAML file (for every page) with a lot of VisualStates and stuff, and try to rearrange the UI for every screen resolution
• Have different projects with a shared project (like with W8.1 universal apps), so that I can focus on the UI on every specific device? This is the approach I'd be more comfortable with, as I'd be able to design platform specific UI elements without problems. Still, I didn't understand how to actually create a shared project and different projects for each device type in VS2015.
• Use that approach with different XAML pages that share the same code-behind file (even I'm not sure how to implement this, and how to implement platform-specific code-behind parts).
• Some other method
I mean, I'm sure I'm not the only W8.1/WP8.1 developer in trouble here, is there some kind of advice I can use? I already watched all the MVA videos about W10 development, but they didn't get into the implementation details there.
Thank you for your help
Sergio
It really depends on your project. If a UI isn't changing too drastically, I would definitely use AdaptiveTriggers. You can do a lot with very little XAML. Check out Microsoft's sample code if you haven't already: https://github.com/Microsoft/Windows-universal-samples/tree/master/xaml_responsivetechniques
If it is changing drastically, you can do it with AdaptiveTriggers, but it's probably easier to have multiple XAML files. A new way to do this in Win10 is to use DeviceFamily. Essentially, just create a folder called "DeviceFamily-Mobile", and stick a XAML view with the same file name in there. More info: http://sharpgis.net/post/2015/04/01/Creating-DeviceFamily-specific-layouts-in-a-Universal-App
Those two screenshots aren't necessarily that different, if you look at using the SplitView Control and the RelativePanel Control.
See this //build talk for more info.
For a long time now, I have been stuck with Windows Forms development (started with VB6, and has continued through to C# .NET 4.5), and I have pretty much hit the limit of what Windows Forms can do, both using pure .NET, and special effects with Native Code.
I have tried to learn WPF and XAML, but I get stuck right at WPF's new designer. It really seems very difficult to use in comparison to the Windows Forms designer.
I want to know if there are any alternatives to .NET's WPF designer, that are more suited to Windows Forms developers?
I like to blog about beginner articles for WPF, and there are a few in particular that may help you out:
Understanding the change in mindset when switching from WinForms to WPF
What is this "DataContext" you speak of?
A Simple MVVM Example
To summarize, the biggest difference between Winforms and WPF is that in WPF your data layer (the DataContext) is your application, while in Winforms your UI layer is your application.
To look at it another way, with WPF your application consists of the objects you create, and you use Templates and other UI objects to tell WPF how to draw your application components.
That's the opposite of WinForms where you build your application out of UI objects, and then supply them with the data needed.
Because of this, the designer isn't actually used that much since your application components are designed in code, and the designer is only needed to draw a user-friendly interface that reflects your data classes (typically Models and ViewModels)
And personally, I prefer to type all my XAML out by hand since it's faster and doesn't make as much of a mess as the drag/drop WPF designer does, although I do use the Designer on occasion to preview what my UI will look like.
So to your answer your question about if there's other WPF designers suited for WinForms developers, I would suggest that instead of looking for another designer, instead look to learn how to use WPF in the way it's meant to be used. Using WPF like it's WinForms means you miss out on much of what makes it so great :)
Well although, some people don't agree, I would also recomment to not use the VS designer. At least not to create an interface. If you may want to get a first impression of your implementation without starting the application, it's a good viewer at least as long no sophisticated things like Styles and Templates are used. But, IMHO, its drag and drop result should only be used as prototype and therefore be discarded after it's no longer needed.
Here are some reasons which are important for me not to use it.
The VS designer is working with fix margins and alignments (which is usually not necessary, if you're using the layout controls), means you have to touch many controls, if the requirements are changed. If you're deep in XAML and the WPF mechanics you can create an applications which can be modified with small effort, regarding the look and feel.
Since the designer is generating the xaml, the composition is not optimal and the UI may perform badly. I didn't measure it, it's just a feeling.
A much better alternative is MS Blend, although the start is everything else but easy. Its drag and drop result is much better that the result of the VS designer.
But it's a pretty powerful tool, which helps you to use pretty powerful elements to create a state of the art UI. I recommend to visit at least a short workshop to get an idea of its opportunities.
Back to your question, IMHO, and I think many people agree, get yourself a good book e.g. WPF Unleashed and later, if you want to know more about the details, WPF Pro. There are a lot of features which are different to Winforms. You won't get to know them by using any designer. I think that's the best approach.
Please also consider that there are many frameworks and libraries (e.g. MVVM light, WPFToolkit) out there, which are already solving some common problems. So it's not necessary to reinvent the wheel.
I know this is an old question but for the benefit of anyone else looking at this, I think I should redress the balance a bit - reading some of the other answers, I get the feeling that some of the 'don't use the designer' sentiment comes from not using it properly.
This tutorial is quite good to get you going and answers some of the criticisms in the other posts.
For instance, you can switch from the Winforms-like margin-based layout that is the default when you drop a control, to a more WPF-ish style by right-clicking and selecting 'Reset Layout'
This video covers similar ground.
I still prefer the VS2010 designer on balance - VS2013 seems to be a bit buggy when dragging and dropping onto TabItems **, (which my current project uses a lot) - but the VS2013 Document Outline view lets you move things around in that view too, which can be a real plus.
Really, though, to get the most out of WPF and xaml you need to be reasonably fluent in both the designer view and the xaml view and switching between them; if you shy away from the designer, you are missing out on something that can help you a lot.
** Edit - although this seems to have been improved in Update 3 for VS 2013, and in previews of VS14, to date I still get odd behaviour at times.
First of all, in WPF (XAML) in Visual Studio deisgner, you should always use the xaml code to build you UI and do not drag and drop you control! You need to keep your code clean. You can use Expression Blend to help you, it's more graphic oriented with drag and drop, but it's not free.
It's not a big learning curve, but I think you should learn how to do your xaml by hand instead of searching for alternative.
I've been through this process as you did. Afterwards I was teaching everyone in my company WPF. There are a couple of important lessons I have learned and everybody I know who works with WPF.
If you are working with UI controls in the code behind, .... Then you are doing it wrong. There is absolutely no need for you to deal with UI controls in the code behind.
You do not need the visual developer for clicking on it. You are much more productive by only dealing with XAML.
Use Copy/Paste. Do not trust in your typing capabilities. It will save a lot of headaches.
Think of the XAML just as a window that loks over the data. In the code behind you are changing the data. In XAML you are defining how the UI will interpret the data.
Converters are amazing. As soon as you get a key amount of Converters, your productivity will rocket Sky high. They will take over the role of the crazy amount of control eventhandlers that hide or resize, or what ever about UI,
It makes UI development fun. Especially once you find out how it likes to play along with Asyc processes. It really takes away a lot of the headaches that were caused by Winforms.
I used WPF very little before and some stuff seemed very different to achieve. Coming from a winforms background, what things will seem different and take you a while to figure out.
Off top of my head, I remember not being able to specify which nodes are selected in a treeview control the way it's done in winforms, if I am not wrong.
I remember the whole MVVM principle..
But its okay now.. we are bffs now! :)
Oh, where to begin? WPF and WinForms seem very different to me. The concept of defining layouts using markup is quite different, although similar to web development. The fact that you need to make an explicit choice of a layout container (for multiple elements) is novel. I remember trying to add a bunch of elements directly within a Window and getting very confused...
I think to take advantage of all that WPF has to offer, you need to have a WPF mindset. For example, you don't have to use styles, templates, and bindings, but those concepts are where the power of WPF lies.
As Daniel stated WPF is different and it needs a different Mindset. You have to forget all the UI side assumptions you made/learned while doing Winforms or other conventional UI side development
I have comeacross so many similar kind of questions in this site. Some interesting once are listed bellow. You can find many here.
What are the most common mistakes
made in WPF development?
How to begin WPF development?
When is Winforms the correct choice vs. WPF?
For your selected node in a treeview the ModelView ViewModel approach works well. People have worked out good design patterns now for this kind of thing making the process much more easy.