I have been writing C#/WPF applications for years, but have started to experiment with some apps using MAUI.
Over time, I have gathered icons and other visual resources in to a class library which has the tags:
<TargetFramework>net7.0-windows</TargetFramework>
<UseWpf>true</UseWpf>
My icons are then loaded as XAML from ResourceDictionaries depending on the application theme etc. This has been a really nice way of having a single XAML file per icon set and loading them all from a single library.
With MAUI, I first attempted to remove the -windows and UseWpf tags so I was compiling pure shared net7.0. This, of course, means that my existing WPF applications fail to find the resources using Pack notation.
I realise I could have one resource assembly for WPF and another for MAUI, but I've already created fairly mature scripts to import new icons to all the icon sets, and if there's a way of sharing a single library, that's what I'd like to do.
Is there a way to achieve this?
Not easily.
Maui might use xaml but it's a different flavour of xaml than wpf.
A maui resource dictionary has different headings to a wpf one. You can't even share a resource dictionary file. https://learn.microsoft.com/en-us/dotnet/maui/fundamentals/resource-dictionaries?view=net-maui-7.0
<?xml version="1.0" encoding="UTF-8" ?>
<?xaml-comp compile="true" ?>
<ResourceDictionary xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml">
Whereas a wpf resource dictionary outer tag would be:
<ResourceDictionary
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
If you stored your resources as xml then you could build resource dictionaries on the fly for both.
You'd have to be really careful you don't use something doesn't work in maui ( or wpf ).
Even then, you'll have complications with things like pictures. Things that work in one will not in the other.
The more I think about it the more I think this is a minefield.
I am doubtful whether this would be practical. I think porting is likely to be much more viable. If your wpf resources are fairly mature then maybe they aren't going to change much.
Related
I've been developing an windows desktop application in Visual Studio 2015, and I've been trying to figure out how to switch between different view files. Essentially when the app begins I can choose which view it is supposed to display first (i.e. MainPage.xaml), however, I have yet to find any resources that describe how to switch between the different views programmatically, say at a button click.
I'm coming from developing an app for IPhone, and in XCode switching views programmatically seems to be the intended way of doing it. My question is how do I switch the views programmatically using C#? And also, is Visual Studio different in that I should be doing this someway else?
Seems like you didn't get your answer.
If you'd like some MVVM startup points, have a look at the following:
The agile warrior: simple mvvm walkthrough
Code project: MVVM basic to advance
Code project: Model-View-ViewModel (MVVM) Explained
Alternatively, you can also have a look at my article Code Project: The Big MVVM Template.
If you'll read the article, you'll see many of the benefits of the MVVM approach (and why you'd want a framework that will help).
If you just get the code sample and run it, you can see an application running and be able to look at the parts that might interest you.
There's also this answer with lots of other mvvm related resources.
First, get to grips with MVVM. There are some good tutorials online for this.
In my experience, instead of switching the View programmatically, it's much more performant to create the views and hide/show them on demand with Visibility.Show or Visibility.Collapsed. This will result in snappy, fast applications.
As noted in the comments, MVVM is a steep learning curve, but it's worth it: an application written in MVVM is very maintainable and testable.
Update
As requested, I will recommend some tutorials on MVVM. You could read a book, but that won't really work as well as watching a tutorial video and following along with it using Visual Studio. There is something magical about copying what the tutor does as they code up the sample, you really start to understand it.
I would recommend PluralSight or, perhaps, Lynda. These are not free, but the quality is excellect and the material is comprehensive. For the record, I have no affiliation with these companies.
Assuming you used a project template, it should have generated a base class called App.xaml as an application starting point, and something like MainWindow.xaml as the base start page.
For WPF/XAML
App.Current.MainWindow = <class that implements System.Windows.Window>
If you are using Xamarin.Forms XAML, than it changes to
App.Current.MainPage = <class that implements Xamarin.Forms.Page>
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.
I would like to let the users of my apps (C# + WPF) to build their own themes and skins.
What is the best way to achive that? Are there some examples or maybe some sort of "skin engine" I need to look for?
Coming from web development I usually use both XAML and images to build the UI... but in this way all sources will be "hardcoded", embedded in the main exe or into some dll...
Instead I would like to have some text files with all the parameters (like colors, spacings, dimensions, font size, etc...) and all the images contained in a folder in jpg or png format.
Is it possible?
Thanks!
I am not aware of any pre-built skinning engines for WPF that allow users to select colors and update the application. However I have used a similar approach to your "text files with all the parameters..." in a WPF application, and it worked relatively well.
We used an XML file with the theme colors/icons/etc. that was loaded at runtime and used to update application resources with the firm-defined colors & images. Depending on your architecture, you could also store the skin/theme in a database.
In order for this to work, a couple suggestions:
Define a standard set of Colors available for use throughout the app (e.g. LightControlColor, ControlColor, DarkControlColor, LightBackgroundColor, BackgroundColor, Dark...). These are the colors defined in the XML file, and will be updated when the skin/theme changes.
Define a standard set of Brushes that you will use in all your XAML. These brushes will make use of the Colors, so a ControlBackgroundBrush could be a SolidColorBrush made up of one of the Colors (from above), or it could be a LinearGradientBrush made up of multiple colors.
Use DynamicResource everywhere rather than StaticResource so that when you update your Color Resources based on the XML file, everything will be updated.
You'll need to update the Colors in the Application.Resources before the main window is displayed since DynamicResources are evaluated when visual elements are rendered. A splash screen is a great way to occupy the user while you're loading, parsing and merging the skin.
We didn't have too many images, but I believe we stored the ones we did have in binary format within the XML.
We built a separate application for creating a skin/theme. This was distributed independently of the main app and was strictly for the purpose of creating & updating skins.
I'm creating a Windows 8 metro style application for navigating a rest api which is essentially the same as a file system. I would like to use the same UI as you get with the File picker and the built in search results.
How can I get the XAML (or ideally XAML+code) used in this UI? Are there any samples? Could I use a tool? Is the code available anywhere?
Thanks,
Jon
The FilePicker is provided as an OS piece of UI that is common across all the WinRT dev environments. There is not any source or XAML available for it.
Just build it, right? The UI is so simplistic, that I think an hour and some TLC and you will have what you want. You can't get the raw XAML as it's in the OS itself, but you don't want it anyway - it's certainly implemented with more complexity than you want or need.
I would offer this one bit of advice. It makes sense to copy the general look of the file picker for the sake of usability. However, do yourself a favor and make something different. There's no reason the user should be confused by the similarity - wondering where their SkyDrive is or something else. You may have already thought of this.
I'm creating my first WPF application and I wanted to understand if there is some kind of best practice when mixing functionality from the System.Windows.Forms namespace.
Basically I want to have a popup window that opens by default in the bottom right hand corner of the users monitor.
I can't find a Screen.PrimaryScreen.Bounds equivalent in the WPF namespaces. The examples I have seen suggest referencing System.Windows.Forms in the WPF Application.
Which led me to the question, is this bad practice?, considering this reference isn't included by default.
I'm going to reference the WPF required resource in my existing windows forms application so that I can use this new WPF Window.
Is there anything wrong with this approach?
EDIT: I have actually found a property that returns information of the primary screen without referencing Windows Forms. The property is SystemParameters.WorkArea, my question of mixing references does still stand though.
Also you should consider resources and performance overheads as your application will have to load assemblies for both Windows Forms and WPF. It was mentioned several times within MSDN forums that WPF/Winforms interopping takes quite a lot of CPU cycles...
I don't think that referencing WinForms, when needed, is bad. Since WPF is still a relatively new technology, it just doesn't have complete feature parity with WinForms yet. For example, to my knowledge none of the standard Windows dialogs (Open File, Save File, Browse for Folder, etc.) have been implemented in WPF yet. The only way to display these in a WPF application is to use the WinForms version, or use P/Invoke to display the Win32 versions yourself. I go with the WinForms version personally, since they already took the trouble of wrapping the Win32 API.
My approach is to use WPF as much as possible, and only fallback to WinForms if WPF doesn't fill my needs. Hopefully over the next release or so of WPF this will become less and less necessary.