I am new in WPF. Created a new WPF UserControl. See that some people uses an app.xaml file in order to set inside application level ressources.
My solution consists of a WinForm and a WPF UserControl. I don't see somewhere any app.xaml file.
How to proceed?
App.xaml is associated with a WPF application. If you've only got a UserControl, there's no application for it to be part of, is there?
Create a WPF application and you'll have an App.xaml to put application-level resources in.
Out of interest, why do you have WinForm if you're using a WPF user control?
EDIT: To repeat my comment: you're not going be provided with WPF Application resources smoothly when you're not creating a WPF application.
EDIT: As noted in Anthony Brien's answer, it seems you can hack it around - but I would strongly recommend against this sort of thing if you can possibly help it. Fundamentally, you're working against the expectations of the platform - and that's never a nice situation to be in.
It is possible to have application wide WPF resources in a WinForms application. Look at http://www.wpftutorial.net/AppLevelResourcesWinForms.html
You need to create a WPF or Silverlight application to get that file
You are actually hosting a WPF control in a Winforms application
If you created a WinForm project, it will not have a app.xaml.
Create a WPF project instead.
This article explains in great detail how to have application wide resources in a hosted/interop scenario:
http://drwpf.com/blog/2007/10/05/managing-application-resources-when-wpf-is-hosted/
The solution path I chose (from the article) is to include App.xaml as a page element
Modify project file:
<Page Include="App.xaml" />
<Compile Include="App.xaml.cs">
<DependentUpon>App.xaml</DependentUpon>
<SubType>Code</SubType>
</Compile>
Add code:
public App()
{
InitializeComponent();
}
public static void EnsureApplicationResources()
{
if (Application.Current == null)
{
// create the Application object
new App();
}
}
Full details are in the article.
Related
I am writing a class library for a WPF VB.NET application and I am trying to get access to the namespace where the classes for various wpf controls are located. What namespace are wpf controls located in? I normally would just google such a question, but i couldnt find anything via that avenue.
If you use a WPF User Control Library you will have all you need there, you can then even add UserControls etc easly to this type of project.
I bag your pardon. I'm very beginner in MVVM. I installed MVVM Light Toolkit V 4.0 and tryed to create a WPF MVVM application project with it. A project was created successfully. There are following folders in the project: "Design", "Model", "Skins" and "ViewModel". I clearly understand the necessity of "Model" and "ViewModel" folders. But what is the purpose of "Design" and "Skins" folders? A folder "Design" contains a file DesignDataService.cs with the following contents:
using System;
using MvvmLight1.Model;
namespace MvvmLight1.Design
{
public class DesignDataService : IDataService
{
public void GetData(Action<DataItem, Exception> callback)
{
// Use this to create design time data
var item = new DataItem("Welcome to MVVM Light [design]");
callback(item, null);
}
}
}
The folder Skins contains a file MainSkin.xaml with the following contents:
<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
</ResourceDictionary>
Explain me please: what is the purpose of "Design" folder (and it's contents) and "Skins" folder (and it's contents) in MVVM WPF application? And where should I place xaml-file that represents the View in MVVM-application?
Design Folder provides Design-Time data. Data that helps you design your UI in VS or expression-blend with dummy data that will not be applied to your project at run-time.
Skins is just a collection of resources in your project. Style's, ControlTemplates and such can go into that folder.
MVVM-light at codeplex have a look through the 2 videos in that page where the author of the library shows how to use Design time data.
The WPF designer in Visual Studio or in Blend is able to run the application during the design time - In this context, design teams means actually during that time you design the GUI of your application. Most of the application designs work only if the design is filled with data, but it makes not sense to call a database or somethings else. In conclusion the folder design contains all class which provide the data for the design time. This behaviour if often called blendability, because of the tool Blend. This links might help for further information:
http://www.robfe.com/2009/08/design-time-data-in-expression-blend-3/
http://www.robfe.com/2009/12/design-time-data-in-expression-blend-3-revisited/
The folder skins normally contains custom designs for your WPF controls. For more information, this url might help: http://www.c-sharpcorner.com/uploadfile/raj1979/skins-in-wpf/
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.
I am trying to find out if an EXE is a WPF app or a WinForms app. Any suggestions on how I can go about this?
I have heard that I could use the Reflector tool, if so how would this be done?
Thanks.
Although generally an application can be classed as 'either' a WPF or WinForms application, interoperability is possible such that a WinForms app can 'host' WPF controls and vice-versa. Since your application sounds like it references both sets of assemblies, it could be using both. Just something to be aware of.
Anyway, I've just opened one of my WPF projects in Reflector and some obvious indications it's a WPF application are:
1) There is an App class that has a StartupUri which is a Xaml file (like this)
public class App : System.Windows.Application
{
// Methods
[DebuggerNonUserCode]
public void InitializeComponent()
{
base.StartupUri = new Uri("Window1.xaml", UriKind.Relative);
}
2) There is a XamlGeneratedNamespace in the EXE
3) In the Resources 'folder' there are .baml files (probably within <Application1>.g.resources).
4) The window classes (if you can find them easily in the Reflector tree) implement:
public class Window1 : System.Windows.Window
, System.Windows.Markup.IComponentConnector {
If you really want to trawl through Reflector in detail, WinForms windows will inherit from System.Windows.Forms.Form so you can easily spot if you have both WinForms and WPF in there.
You can check the .exe with code, you do not need Reflector.
Simply find a type in the .exe assembly which inherits from the System.Windows.Application class which is from the PresentationFramework dll (you can do it with reflection).
Now, this isn't a 100% sure method, since theoretically someone could be creating a class which inherits from the wpf Application class, and then not start the app. The definite way is to check in Reflector if that class' Run() method is called.
And the programmatic way to check if the current application in which your code is running is a wpf app is like this:
public static bool IsWpfApplication
{
get { return System.Windows.Application.Current != null; }
}
Open it with reflector and see whether it references one of the PresentationFramework DLLs (then it's likely WPF) or System.Windows.Forms.dll. Note that applications might reference both - in that case, you can't really tell.
Maybe it's easier just from looking at the application. WPF applications are rendered smoother, even with standard controls.
Generally one dead give away is that WPF applications tend to have a different looking focus rectangle on focused items such as buttons or listboxes. The standard Windows focus rectangle is 1px wide and on WPF apps it seems to just look... different.
Also, WPF apps render most elements to memory bitmaps whenever they need to perform some kind of animation and this results in a "fuzzy", almost anitaliased look whenever the particular animation takes place and is displayed onscreen. This effect is noticed in things like, menu highlights, scrolling or general button text after you click.
First I just want to say I am new to WPF, so please excuse my ignorance...
I am creating a .Net plug-in for Rhino 4.0. With the plugin I am developing a UI using WPF.
The Rhino 4.0 CAD engine is an MFC/Win32 application. The plugin will execute after the application is run, and it creates the WPF Window and then "sucks" the MFC Window into it.
So my question is, does WPF look for an App.xaml file to get to Application level resources if the hosting application isn't a WPF app?
If not, what is the best way to store application level resources?
Thanks,
Jason
App.xaml is used as a part of a partial class App : Application.
If your application does not have a WPF based Application class,
you can manually load dictionaries and merge with the application and create a main window and show it (access via static methods of Application class).
Code goes kind of like this.
var reader = new XamlReader();
var dictionary = reader.read("path to xaml file") as ResourceDictionary;
if (dictionary != null)
Application.MergedDictionaries.Merge(dictionary);
var mainWindow = new MyMainWindow();
mainWindow.Show();
WPF projects will - by default - generate an entry point for your application. This entry point constructs and initializes your Application-derived class for you. If you need, you can always create your instance manually, and store application-level resources in it:
App app = new App();
app.InitializeComponent();
app.Run();
Have you tried storing your resources at what MSDN refers to as the 'theme level'?
Within a folder called "<root>\Themes" have a file called generic.xaml.
I haven't tried this for a project that wasn't a WPF application, but the approach might work for you.
my guess is it has to do with how does rhino run your plugin does it run it as a seperate process or does it just call some thing you have defined?
If it does call a function you defined then you could just put the code there that will start the window?