I (appear to) have successfully created a UWP package for my WPF application using the following guide:
https://learn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-packaging-dot-net
Now I would like to take advantage of the AdControl class to display banner ads in my project, as detailed here:
https://learn.microsoft.com/en-us/windows/uwp/monetize/adcontrol-in-xaml-and--net
Is this possible? I don't see the "Universal Windows" section under References for my WPF project, which I can guess is because it’s not an original Universal Windows project. I do see it under References for the UWP package wrapper project I created using the guide above, but that doesn't help me show ads in the WPF project.
Any help appreciated.
You can add Universal Windows reference and use the API in your project as described here but you cannot use AdControl since XAML/UI in WPF is not the same as XAML in UWP and the AdControl is a UWP XAML control:
As mentioned above, 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.
I added references to WinRT dlls to a WPF project and I want to use SwapChainPanel inside of a WPF window.
Is it really possible? For now I cant get it work.
The NuGet package description for Microsoft.Toolkit.Wpf.UI.Controls mentions a SwapChainPanel but I have not found any samples using this control in WPF.
SwapChainPanel : Provides a hosting surface, where Microsoft DirectX swap chains provide content that can be rendered into a XAML UI. A SwapChainPanel element is a key component for an app that renders Microsoft DirectX graphics and then presents those visuals within a XAML page.
It's not currently officially supported - might require some private APIs in Windows, though since Stardock could implement its ModernMix - there might be some way to get it working. The thing is though - you don't have to do that. You can render content with DirectX to a WPF window in other ways. I haven't done that and it might be quite a bit of work to do, but so is anything in DirectX. You can look into DirectComposition or D3DImage class. Perhaps the article on using Direct2D with WPF can be a good sample solution.
You dont have to, as says Filip Skakun, but you can ! Just give a try to SlimDX or SharpDX. They're DirectX's implementations in C#.
I am trying to integrate WPF into a legacy MFC application. I am unable to include the /clr switch to mix managed and unmanaged due to the restrictions of other projects in the solution. I need the WPF window open up as a child window in the main MFC application. I have been investigating different ways for the past two weeks but have hit roadblock with every implementation try. If anyone has successfully integrated this type of implementation, I would appreciate some direction. I have been able to integrate with a Win32 app, but could not translate this to an MFC app. Thanks everyone.
I believe that WPF requires .NET, therefore what you need is to create a separate DLL or EXE for the WPF parts. hat new project could be the container for .NET code and your main MFC would launch this separate project.
You can write a WPF front end that launches C++ apps with the desired command like switches, similar to what Visual Studio 2010 is doing to compile your code and show the results in the output pane. In this way you can avoid having to hack message loop code to support both frameworks .
You may show your Dialog using a COM interface
I have a MDI based rather huge application that has plugin Architecture.
The plugins MFC unmanaged DLLs that bring many unmanaged dialog(CDialog base calls).
I am planning to initially only build the main GUI framework in WPF and keep the plug ins still in MFC, and have Managed wrapper dll which enables me to call this dialog in a managed application.
Slowly change 100+ plugin we have over the period of time.
I would like to have new application also a MDI with docking support. So I am planning to use 3rd part libraries from ActiPro and Syncfusion.
My question is
1) How can I add / remove menu items in a WPF application based on the need of the plug in that is loaded ?
2) How will I able to dock my MFC Dialogs in a WPF application as if they were created using WPF.
Any help is greatly appreciated.
Shashi
I've done .Net development for awhile but I'm new to the WPF technology. What is the supposed purpose of App.xaml? Also, what type of xaml code do you usually put in it? It seems like for simple applications it could be ignored and left untouched. Is this true?
App.xaml is the declarative portion of your code (usually generated by Visual Studio) extending System.Windows.Application. For example, Expression Blend can use App.xaml to share a Resource Dictionary or a design-time data set with your entire application. And, because we are using Microsoft products, whatever Expression Blend can do auto-magically, we can do by hand in Visual Studio.
Now the tangent: To me, to ask about the purpose of App.xaml is to ask about the purpose for System.Windows.Application. Feel free to accuse me of changing the original question (let the digital brutality ensue).
You can’t just open a System.Windows.Controls.Window in any Assembly you like… Chris Sells is likely telling me this in his book. I began to understand the purpose of System.Windows.Application while using MEF and MVVM Light to display WPF windows in DLLs (not EXEs). I got errors like this:
The type 'System.Windows.Markup.IComponentConnector' is defined in an assembly that is not referenced.
or
The type 'System.Windows.Markup.IQueryAmbient' is defined in an assembly that is not referenced.
The above error is simply saying that I’m trying to open a WPF Window inside of a DLL and not an EXE. Then, there’s this error:
The component 'Songhay.Wpf.WordWalkingStick.Views.ClientView' does not have a resource identified by the URI '/Songhay.Wpf.WordWalkingStick;component/views/clientview.xaml'.
This boils down to the absence of a facility that associates WPF Window XAML with the WPF “code” (an instance). This facility is associated with WPF EXEs and not WPF DLLs. Visual Studio auto-generates a WPF EXE class called App.g.cs (in your \obj\Debug folder) with this call in it: System.Windows.Application.LoadComponent(this, resourceLocater) where resourceLocater is a badly named variable containing a System.Uri pointing to the XAML like ClientView.xaml mentioned above.
I’m sure Chris Sells has a whole chapter written on how WPF depends on System.Windows.Application for its very life. It is my loss (quite literally of time) for not having read about it.
I have shown myself a little something with this unit test:
[STAThread]
[TestMethod]
public void ShouldOpenWindow()
{
Application app = new Application();
app.Run(new Window());
}
Failing to wrap a new Window in the System.Windows.Application.Run() method will throw an error from the land of COM talking about, “Why did you pull the rug from underneath me?”
For simple applications, it is true, it can be ignored. The major purpose for App.xaml is for holding resources (style, pens, brushes, etc.) that would would like to be available through out all of the windows in your application.
It is true. App.Xaml is some sort of central starting point. You CAN use it, or you CAN start your first window (it is defined in the app.xaml) manually. There are some lifetime events there centralls (like application start).
Storing resources that are used across the whole application.
Application is the root of the logical tree.
It is like Global.asax if you are coming from an ASP.NET background. You can also use it to share resources throughout your application. Comes in pretty handy for resource sharing.
App.xaml is a major part of wpf application.
It contains major four attributes
1.X:Class->used to connect you xaml and code-behind file(xaml.cs).
2.xmlns->To resolve wpf elements like canvas,stack panel(default one).
3.xmlns:x->To resolve XAML language definition.
4. StartupUri->To give start window when application is launching.
++++++++
App.xaml is the declarative starting point of your application. Visual
Studio will automatically create it for you when you start a new WPF
application, including a Code-behind file called App.xaml.cs. They
work much like for a Window, where the two files are partial classes,
working together to allow you to work in both markup (XAML) and
Code-behind.
App.xaml.cs extends the Application class, which is a central class in
a WPF Windows application. .NET will go to this class for starting
instructions and then start the desired Window or Page from there.
This is also the place to subscribe to important application events,
like application start, unhandled exceptions and so on.
One of the most commonly used features of the App.xaml file is to
define global resources that may be used and accessed from all over an
application, for instance global styles.
+++++++++
Source : http://www.wpf-tutorial.com/wpf-application/working-with-app-xaml/
Here is an updated answer in case people are still looking.
There is this excellent article on WPF, and the link specifically puts you at the App.Xaml point to begin teaching you the things you can do with it.
WPF is easy for the first very simple app or two. However, due to the increased flexibility of the framework, you need these types of tutorials to help you understand what can be done from where (in the various application files).
https://www.wpf-tutorial.com/wpf-application/working-with-app-xaml/
Good luck.