Hopefully a simple question; I seem to recall seeing somebody at one of the recent Microsoft conferences say that some of the UWP application functionality was to be made available within WPF/Desktop. Unfortunately, I can no longer find (or remember) which of the many videos this was from (though it was probably Build or similar on Channel9).
Is it therefore possible to use UWP controls within a WPF application? Basically I want the look and feel of an "app", including some of the new controls (RelativePanel, SplitPanel) and the themed buttons etc., but I need the power of the full desktop - such as access to the full file system.
Thanks.
I think you are referring to the different Bridges to port apps to Windows 10 from for instance, IOS, Android, Web, Win32, etc. and still take advantage of Windows 10 features and APIs. Specifically, I think you are talking about the Bridge to bring in Win32 apps. You can find the bridges listed here.
https://dev.windows.com/en-us/bridges
•"Project Centennial": This toolkit will enable desktop developers to package and publish their existing .NET and Win32-based Windows applications to the Windows Store. Developers can also use Centennial to call common UWP APIs and services."
Related
One example would be the new notification APIs for Windows 10 universal platform. Can I use this set of APIs in a WPF app? If so are there any limitations?
Links to documentation regarding this would be much appreciated.
It is possible to use UWP APIs in a WPF app. However not all UWP APIs can be used in a WPF app.
There are exceptions to the rule that Windows 10 APIs are accessible from PC software. The first big exception concerns XAML UI APIs. The XAML framework in UWP is different from the one in WPF and you really don’t want to be mixing them up, anyways.
The second set of APIs that you can’t use are ones that depend on an app’s package identity. UWP apps have package identities while PC software does not. Package identity information can be found in the app manifest file.
How do you determine which Windows 10 APIs require a package identity and which do not? The easiest way is to refer to this MSDN topic.
For how to access the Windows 10 APIs from WPF, please refer to this answer and also see the blog Calling Windows 10 APIs From a Desktop Application (Please note the name of the references in the blog is not right, so I'd suggest you refer the answer in SO).
No, You can't - at least for now -
But there's a progress on a project called "Centennial" Which will enable you to do so.
More see "bridges".
Yes, you can now.
https://blogs.windows.com/buildingapps/2017/01/25/calling-windows-10-apis-desktop-application/
I'm looking for a point in the right direction. We're thinking of building an app in our office, and one of the features we're looking at is to be able to open and save files from our app in other apps and applications.
We came across the File Picker Contract which, with some simple examples, seems to be what we're looking for. But the one thing missing is it only seems to be available in other Universal apps (but it doesn't seem all of them).
Using multiple examples, we were able to see our apps in our other apps, but I'm hoping to take it further. For example, I thought Office 2016 was a Universal app, so shouldn't File Picker Contract apps appear in there as well? And is there a way to add it globally to all File Open / Save Pickers (like from notepad, or the snipping tool)?
This MSDN page (article) seems to suggest the picker uses a single, unified interface. Shouldn't that be the same interface the rest of the operating system uses?
Thanks in advance.
If you have to support Classic Windows apps, filepickercontract is not a right solution. It's only applicable for 'modern'... Win8.1 store or Win10 UWP apps.
And, current office2016(for desktop) is not an UWP app, I believe. UWP ver of Office 2016 is only applicable for Win10 Mobile.
One alternative is make a shell extension. By using this, you can extend the explorer's shell space and add your own items to explorer tree. But shell extension is so complex, old and only applicable for desktop devicefamily. I don't think that now is a nice timing to implement it.
I hope this answer could help you.
Recently, I tried to make a battery app (C#, store app) for Windows 8.1
(I am using VS2013, tried also VS2012 with the same result).
As it turned out, I need to add a Reference to the project - but I cannot add anything in Reference Manager: it says "All of the Framework assemblies are already referenced". And all what I need is to get System.Windows.Forms - when I search for it, nothing appears.
Any ideas, what can I do?
(Please tell me if I forgot something essential)
Windows Store Apps are build, from scratch, on new technology stack , So Windows Form and WPF are not part of Windows Store apps.
Windows store apps and Windows Forms apps has there different set of
APIs.
Windows store apps are used to known as known as Metro apps and Right now they have been merging the stuff(don't want to go into the details).
This will give a basic knowledge about this new Technology
So, above are the just a small hints about the differences. Actually, It is not possible to explain all the stuff here. Just explore.
We have existing Windows Store application which is developed using C# and XAML. We want to port the same to Windows 8 Mobile application. Is there any Guidelines available for this ?
Well at first I would start figuring out the differences
http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj681690%28v=vs.105%29.aspx
http://blog.markedup.com/2013/07/winrt-windows-phone-8-code-sharing-pitfalls/
When I ported two of my (smaller) apps, I put as much in a PCL (portable class library) as I could. All the stuff that remained in the project itself needed to be rewritten. If you have well-maintainable code, there should be only UI (what you have to adapt anyway) and very few platform specific code (like accessing filesystem, camera or whatever) left. This is the part you must redevelop.
Dnt know how you have made these applications well If you have followed MVVM pattern then it is very easy to port windows and windows phone apps from one to other. You just need to take care of new XAML UIs every thing except some platform specific liberalizes will work. While making any of windows store and windows phone application you should use the liberaries that both platforms can consume. For example you can use LEX.db for the database.
here are very good explanations for it.
sharing code between windows phone and windows 8 app -1
sharing code between windows phone and windows 8 app -2
hope this will help
The answers given so far are quite good. One thing to note is that Windows Phone 8.1 is about to be released, which will share many of the WinRT libraries. This will mean that in a few months (as early as May), the shared libraries between the two platforms will greatly increase. You can download the leaked SDK to see what some of the changes will be.
Not that you should wait until then, and creating a PCL is definitely going to help you (especially if you want to later move to iOS, Android as well). It's just something to keep in mind.
Ok, I have a question to which, despite my best efforts, I have not been able to solve. I searched the internet, and this is one of those that is particularly difficult to search for, but it seems that no user of Windows 8.1 nor any developers developing for Windows 8.1 has posted to any website asking how to do this (I could be wrong, of course).
What I am trying to do is make a Windows Store app targeting Windows 8.1, that takes advantage of multiple Windows. To see what I mean, open up metro ie, right click on a tab, and click "open in new window." This is also in the mail app, where you can open a single message in another window, which behaves like a separate app, and can be snapped like so. It's a new feature of the Windows 8.1 OS.
But I can't for the life of me figure out how to do it in C# and XAML. Does anyone know how? Thanks.
Alex
There are new APIs in Windows.UI.ViewManagement, namely the ApplicationViewSwitcher and ProjectionManager classes. The former is for working with multiple independent views that the user can arrange side by side on whatever monitors they have, which is what IE and Mail use; the latter is for working with multiple monitors.
See the Application Views sample along with the Projection sample for working both scenarios in code.
Might be bit late with my answer, nevertheless I had your similar apprehensions about the "Dismal Support Refs" for this subject, when I first began searching the topic. However I have been able to overcome this and use the feature in my apps. There are some good refs available; The Windows Dev Centre has a Quickstart ie "Quiskstart Creating Multiple Windows", a Good guide is the "MultipleViews" Sample, With the following providing additional support.
1) "Be two places at once using multiple windows" at
https://blogs.windows.com/buildingapps/2014/01/09/be-two-places-at-once-using-multiple-windows/#pBHiQtDSPFrCA7Gv.97
2) "MultipleViews for Windows 8.1 apps" (parts 1-3)
http://www.kraigbrockschmidt.com/2013/11/21/multiple-views-creating-view/
BQ at WATERVIEW