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.
Related
In a Silverlight application that doesn't run in a browser, is it possible to create a new top-level window? Or at least a child window?
I found some solution using the ChildWindow class, but even though my project is configured for Silverlight 4, that class can not be found.
I have a UserControl (XAML file) that I want to show as a new window. Using a tab control is not really an option unfortunately as the user has to be able to arrange windows to see more than one at once.
Any suggestions?
ChildWindow is part of the SDK, you need to add the System.Windows.Controls.dll to access the ChildWindow type.
I'm not sure you can get the ChildWindow to do what you are expecting. A ChildWindow is designed to present a window in a modal manner. However this modal behaviour is really a function of the ChildWindow template. It is possible to re-template to remove the modal behaviour. However I've never tried to manipulate multiple child windows. You could give it a go, the big question would be what happens if you close Child windows in a different order in which they were created?
In order to use a ChildWindow to present your UserControl it would probably be best for you to derive from ChildWindow, instead of UserControl. You may even find it would ultimately be better for you create base class between your specific Xaml and ChildWindow where you would put code that is common to all your windows.
I might be worth you noting the Silverlight 5 will support multiple windows.
At best, I am a UI novice, but I am a pretty good OO developer (if I don't say so myself). I am confused as to how to work with the designer. I am developing a Windows Forms application. I have a control (TabPage) that I derived from System.Windows.Forms.TabPage that I want to place on a System.Windows.Forms.TabControl control.
public class MyTabPage : TabPage
{ ... }
I am not sure how to get the designer to use my control.
A fellow developer looked at this for me as suggested that I add more information.
I've prototyped a WinForms application. The application has a TabControl, with three tab pages on it. Each TabPage has a SplitterControl with a DataGridView control in each half of the splitter. The two DataGridView controls form a master-detail view of some data we need to edit. I've added a bunch of event handlers to each DataGridView control and each time the handler code is placed in the form. The form is getting pretty crowded and would like to use OO techniques to clean things up.
I would like to redo the prototype now and because each TabPage is behaviorally identical, I would like to use OO to abstract away some of the complexity. This is where my lack of experience with the designer comes in. There must be a way to use the designer for something more complex than my origonal prototype.
You aren't really changing the behavior of the TabPage, it's just a container after all :). The TabPage and TabControl are rather tightly coupled, and they probably should be. Your "control" is what should be placed on the TabPage. So define your user control as a panel with a splitter and two datagridviews and then just drop your user control on each TabPage in your app. The Tab Control/Page tandem will still work automatically and your custom code will be in the appropriate control.
Unfortunately, there's no real practical solution to your problem. You'd have to create a custom TabControl as well and give it its own designer so that it will create instances of your derived class instead of the default TabPage class.
Sadly, the TabControlDesigner class in System.Design.dll is internal and can't be derived from. You'd have to write a complete replacement for it. That's difficult, it is a pretty advanced designer. You could have a look-see with Reflector to find out what it takes.
UserControl
Simply create a user control that contains your control. Then it will be available in the ToolBox window of Visual Studio.
For more details, Understanding the User Control Designer...
A User Control is similar to any other
class, but with the added ability to
be placed in the Toolbox and displayed
on a form.
The tutorial differs a bit from Visual Studio 2010 but I'm sure you will get through it.
TabPage Control
As for the TabPage control, you can't use it stand-alone in the designer. It must be part of a TabControl.
The TabControl is built to contain TabPage controls. If you use the designer to add/remove any TabPage, in the back-end it does "new TabPage", it can't determine that it needs to create a new instance of your derived class of TabPage.
Other Suggestion
A TabPage is just a container, I can't figure out why you need to override the TabPage control. I know you have added some information to your question but you may have to revisit it again so we can better understand.
Since the TabPage is a container, you should create a UserControl which contains your SplitContainer and DataGridViews. Therefore you would be able to reuse that UserControl on each TabPage.
The designer is just a complement to UI programming, it is not mandatory. You can add a UserControl to a TabPage without using the designer.
I may be off the track here, if so please provide more details. A visual prototype of what you need may help.
It's been a while, but I thought I would answer this question.
I was able to get the OO implementation I wanted by splitting the control up. The control is implemented pretty much the same as the prototype. I then created a control binder class hirearchy with derived classes to contain the specific behavior(s) I needed. The control has a reference to the binder base class and calls binder functionality as needed. The derived binders override properties and methods as necessary. Pretty much a textbook OO solution.
Where I was stumbling was in thinking that I needed to have a control hirearchy.
Thanks everyone for your help. I was under some pressure when I asked this question. It's amazing how much I've learned in the months since.
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 relatively new to WPF, and some things with it are quite foreign to me. For one, unlike Windows Forms, the WPF control hierarchy does not support IDisposable. In Windows Forms, if a user control used any managed resources, it was very easy to clean up the resources by overriding the Dispose method that every control implemented.
In WPF, the story is not that simple. I have searched for this for several hours, and encountered two basic themes:
The first theme is Microsoft clearly stating that WPF does not implement IDisposable because the WPF controls have no unmanaged resources. While that may be true, they seem to have completely missed the fact that user extensions to their WPF class hierarchy may indeed use managed resources (directly or indirectly through a model). By not implementing IDisposable, Microsoft has effectively removed the only guaranteed mechanism by which unmanaged resources used by a custom WPF control or window can be cleaned up.
Second, I found a few references to Dispatcher.ShutdownStarted. I have tried to use the ShutdownStarted event, but it does not seem to fire for every control. I have a bunch of WPF UserControl's that I have implemented a handler for ShutdownStarted, and it never gets called. I am not sure if it only works for Windows, or perhaps the WPF App class. However it is not properly firing, and I am leaking open PerformanceCounter objects every time the app closes.
Is there a better alternative to cleaning up unmanaged resources than the Dispatcher.ShutdownStarted event? Is there some trick to implementing IDisposable such that Dispose will be called? I would much prefer to avoid using a finalizer if at all possible.
I'm afraid that Dispatcher.ShutdownStarted really does seem to be the only mechanism WPF provides for disposing of resources in UserControls. (See a very similar question I asked a while ago).
Another way to approach the problem is to move all of your disposable resources (if at all possible) out of the code behind and into separate classes (such as the ViewModel when using the MVVM pattern). Then at a higher level you could handle your main window closing and notify all the ViewModels via a Messenger class.
I am surprised you don't get the Dispatcher.ShutdownStarted event. Are your UserControls attached to the top-level window at the time?
The IDisposable interface has (almost) no meaning under WPF, because the mechanism is different from Winforms. In WPF, you must bear in mind the visual and logical tree: that's fundamental.So, any visual object generally lives as child of some other object. The base of the WPF building mechanism is to attach the visual object hierarchically, then detach and destroy when they aren't useful.
I think you may check the OnVisualParentChanged method exposed since the UIElement: this method is called either when a visual object is attached and when is detached. That could be the right place to dispose the unmanaged objects (sockets, files, etc).
I was looking for this too and after testing differents options I implemented the solution of venezia
protected override void OnVisualParentChanged(DependencyObject oldParent)
{
if (oldParent != null)
{
MyOwnDisposeMethod(); //Release all resources here
}
base.OnVisualParentChanged(oldParent);
}
I realized that when parent call Children.Clear() Method and had already items added to Children, DependencyObject had a value. But when parent added an item (Children.Add(CustomControl)) and children was empty DependencyObject was null.
While others have given you really useful information about this problem, there is a little bit of information that you may not have that will explain a lot about why there is no IDisposable. Basically, WPF (and Silverlight) makes heavy use of WeakReferences - this allows you to reference an object which the GC can still collect.
I've got this difficult when I'd used some connection to the database, using some IDbConnection implementation driver or Entity Framework.
I've found in these cases the recommendation is to keep one object connection/context per window, to be able to track changes/transactions. (link)
So I've overridden the OnClosing:
protected override void OnClosing(System.ComponentModel.CancelEventArgs e)
{
base.OnClosing(e);
this._context.Dispose();
}
The context can be my ViewModel/Control which implements IDisposable to clean resources.
Sample use of OnClosing to dispose of resources (link)
I have an existing WinForms application for which I'm now designing new bits in WPF. Things are going reasonably well and I have run into my first need for a dialog.
I'd like to do the dialog in WPF. It appears as though I'm going to need to do a UserControl for the actual content and then host that content via a WinForms form with an ElementHost (since UserControl has no ShowDialog() method).
And that's where my question is. How does that work? Best I can tell, the WPF UserControl doesn't even have a DialogResult property (which makes sense given that it has no ShowDialog() method) - it looks to me like I'd need a WPF Window control - and I don't think I can use that in this case.
Struggling with the basic flow and setup of things here. Can someone shine a light?
Is this even possible?
You can open a WPF window from a WinForms application.
Just create the window and call ShowDialog(). The CLR will load the WPF framework and open the window.
If you want your interop application to work mostly like a WinForms app, then the approach you describe works fine -- I've pretty much the same thing in my interop cases.
WPF supports MessageBoxes (albeit a slightly different version than WinForms), and you could put something together using WPF Windows (extending it by adding something similar to DialogResult). However, the provided WPF controls suggest that they're trying to change UX interactions to minimize dialogs, particularly modal ones.
To make your life easier though, I would create a WinForms Form/ElementHost subclass specifically for dealing w/hosting WPF content, and depending on how clean you like your "using" declarations, wrapping your own DialogResult-like enumeration so you don't have to include the System.Windows.Forms namespace which can make your WPF code-behinds more cumbersome.