0

How can I expand the implementation of a wpf using my own custom classes? In particular, I want to create new C# classes on a wpf beyond the ones that derive from App.xaml and MainWindow.xaml. Should I add them directly on the project? If so, can I use references of the MainWindow elements inside them in order to tweak their functinality and add new tasks? Should they derive from the MainWindow class?

What is generally the most reasonable way to expand the implementation of a wpf to other new classes?

heisenberg
  • 9,665
  • 1
  • 30
  • 38
arjacsoh
  • 8,932
  • 28
  • 106
  • 166
  • Check out the MVVM design pattern: [SO MVVM tutorial question](http://stackoverflow.com/questions/1405739/mvvm-tutorial-from-start-to-finish) – Matt Ellen Oct 29 '11 at 21:44
  • 2
    What exactly are you trying to accomplish? Usually you wouldn't derive from a specific application or page class at all, you'd just create a new app (new whole program) or new page. If you're trying to customize the way your app or controls look, you'd usually use data templates, styles, user controls, and custom controls, in that order of frequency and difficulty. – Merlyn Morgan-Graham Oct 29 '11 at 22:06
  • Updated and more detailed question on http://stackoverflow.com/questions/7943872/expand-the-functionality-of-wpf – arjacsoh Oct 30 '11 at 08:12

2 Answers2

0

That is a rather broad question and where to place classes and from what classes to inherit are quite different problems. Both are ultimately a question of architecture though and what the right architecture for your application is cannot be answered here. It depends on what your application is supposed to do and how it should be done, all that should be planned out before doing anything with classes. You might want to read some smart book on topics such as software engineering and software architecture.

H.B.
  • 166,899
  • 29
  • 327
  • 400
0

Ultimately you should get a good book on WPF, read it, and type all the examples into your editor. Simply trying to dive into an API with absolutely no example and no concept of how the architecture works is not going to get you anywhere very fast.

To answer your specific questions, though:

Should they derive from the MainWindow class?

No. To write the GUI for a WPF application, you rarely will have to use inheritance that isn't already written for you when Visual Studio generates a new app, a new window, or new user control.

It might make sense to use inheritance in your code somewhere, but rarely in the GUI code itself, and certainly not on the window or app level. The only manual use of inheritance will be for implementing custom WPF controls (the least frequent and most painful option for extending your GUI).

How can I expand the implementation of a wpf using my own custom classes?

It isn't clear what you're trying to do, so I'll try to cover all the cases.

UI

If you want a new application, usually you wouldn't derive from a specific application class at all, you'd just create a new WPF project (a whole program). Visual Studio will then create new classes for you that inherit from Application and Window.

If you want a new window, the same thing is true. You'd just tell Visual Studio to create a new window, and your classes would automatically be created for you, and they would inherit from Window.

If you want to add existing controls to a window, don't derive from anything. Go to the UI designer, and drag+drop controls from the Toolbox onto the page. Or edit the XAML for that window directly.

If you want to customize what happens when a user clicks on or works with a control, write event handlers for those controls. Or when you're comfortable about this, read up on data binding and the MVVM design pattern, since it will help you write cleaner programs.

If you're trying to customize the way your app or controls look, you'd usually use data templates, styles, user controls, and custom controls, in that order of frequency and difficulty. Except for custom controls, none of those involve manually written inheritance. When you add a User Control in WPF, Visual Studio will write a class that inherits from something, but you don't have to worry about that fact.

Non-UI

If you're trying to write the guts of your application, you probably should avoid writing any UI code.

It is a good practice to separate your UI from your main application guts. That way if a brand new technology comes out, you can strip off the UI, and throw the guts into a new program. Or if you decide to put those guts into a web page, that will also be possible.

You can reference this new code from the code-behind in the UI, or using the MVVM design pattern (which you should eventually read up on), but you should avoid mixing your UI specific code and your non-UI code as much as you can.

This means you won't inherit from any UI classes in order to implement the guts of your app.

Merlyn Morgan-Graham
  • 58,163
  • 16
  • 128
  • 183