Develop Reference

Design time events in WPF?

I am using Autofac with my WPF project.
At design time for some controls, I set the data context of these controls to a designer-specific view model. This view model then injects some services in through its constructor.
That's all fine. But how can I manage lifetime scoping for this? Is there any way to hook up to an event and dispose my Autofac container when the design-time phase is done?

You've said in comments:
The problem is that some of my services (for instance a hotkey service) is using the RegisterHotkey API. For that service, it's important that it is unregistered when Visual Studio is done rendering my design.
In general, those should not even get registered first when your component is in DesignTime. Designtime if for previewing the layout and inspecting view modes/states, not really for testing (though it's very tempting sometimes).
When in designtime, all interactivity of the component should be disabled. VisualStudio tries to do that, you will notice that many interactivity events/triggers are not invoked or passed to your component. However, it sometimes fails badly at this, like in case of Popups (and therefore Dropdowns, Comboboxes, etc) you can sometimes force to actually open in design-time and it yields very strange/unstable/otsafe results.
This is why you shouldn't fully trust VS and the design-time mode to "just work". You probably already know well that poorly written component can, in desing-mode, try for example to connect to a database. It shouldn't happen. Usually.
I'd say, refactor that hotkey-registering bits out into some service and stub/nullify/disable it when you detect designtime mode.
I doubt they worked in designtime, but if you needed these hotkeys to flip some switches in VM on and off, or to invoke some behavior, bind that switches or behavior to a few new properties, and instead of pressing hotkeys, set them in the designer or by designtimedata to check the effect.
Just FYI - I never researched this for WPF/XAML, but for WinForms, each component could come with a special "designer" component. VisualStudio used that 'designer' component for preparing, mantaining, rendering, editing and serializing the edited component. You could actually write a designer for your custom control, and that designer could display extra windows with custom editors, and so on. Toolkits like DevExpress heavily relied on that. I'm not sure if that there is a similar framework for XAML components. I doubt it's the same, but there may be some similar concepts kept. Anyways, I wouldn't dig into this on your place, not for such things. It's not worth it unless you really want to start extending the Designer with your custom plugins.

How to make UserControl dependencies required at design/compile time?

I'm creating a UserControl that exposes some dependency properties, which must be populated for the control to work.
When I use the control in XAML, I can provide values for the dependency properties. But if I fail to set all values, it won't be apparent until run-time (exception will be thrown).
Is there any way for a UserControl to mark certain dependencies as required? If this were a plain C# class, I would make its dependencies as constructor parameters. But I'm not sure what's the right way to something similar in the WPF/XAML world.
We're using .NET 3.5 and VisualStudio 2008.

A possible solution would be to let the control render an error message in its visual area, that during design time hints the developer at these properties and urges him to assign values to them.
An example of such a behaviour is the Bing Maps Control, which requires its CredentialsProvider property to be set by the application programmer. As long as the CredentialsProvider isn't set, the map shows a large label in its center with an appropriate message.
In contrast to the Bing Maps Control you may consider to show such a message at design time only and during runtime throw an exception instead.

Workflow with C# in Visual Studio

I normally code with PHP, I am used to opening up my editor of choice and going away at it, coding classes,methods, etc. It is fairly easy as there is no GUI to worry about.
Last night I spent the whole night following a couple tutorials with C# in Visual Studio, it's turning out to be harder then I thought it would be. Once thing that I am not use to is, all the tutorials have you add a form object like a text box or button, then have you double clikc it to get to the code part, you then enter some code for that method. Then back to the form and re-peat
This seems very hard as you are never really working on "just the code" so 1 question is, is it always like that or just because i'm new and following tutorials?
Another question, when I see source code online to do certain functions, say I see a class I would like to try using, how can I use that class in the existing form class created by VS, do you somehow import other classes or do you add them right to the form code you are working on?
I'm sure that didn't make much sense but hopefully it does to someone, i'll try wording it better if not.
I should add that this was with WPF, also I feel like you have to learn 2 languages, the C# which has very similar syntax to PHP so that doesn't seem too difficult and the for GUI that's like a whole diff language

You can download the classes you are interested into.
Then you go to the Solution Explorer panel and you add existing items.
This will COPY the files to your project.
In order to use those classes you need to declare that you wan to use them.
So, what you have to do is to say something like
using FooNamespace;
Then you are ready to use the classes.
The name space is declared right before any class. You can go edit it.
Now about the forms. Each form is a Class and it consists of three files
ClassForm.cs
ClassForm.designer.cs
ClassForm.resx
You ONLY need the first one. Right click and view code. You can go there and use it.

Many questions, Many answers
Difficulty and Repetition
you can add form objects via the designer or you can hit the source button (CTRL-PgDn). From there you can edit elements in asp and html just like any php IDE. I do most of the work in source. I am a real programmer so I can never do the drag and drop. With intelligence and time you learn the properties and what to do.
to make complex pages you just have to know what you are doing.
What I started with VS I had the same feelings as you, but i have gotten into the flow of it.
As far as the code behind, you are just hooking methods up to the asp elements that get called by the built in code. You can add your own classes, functions, everything in the code behind or in separate files, just like c++, php, whatever.
Hope that helps, VS is really powerful and runs smooth when you learn where things are, been using it for years now and I'm still learning. Bottom line, never use drag and drop and just play with it.

unfortunately the .net world love drag-drop controls. so most tutorials are designed around this concept. drag a textbox on the to form. drag a button onto the form. double click button image to get the click handler.
it's not needed, it's just the approach for most people using visual studio. being that this is a WPF project everything can be done from code, or xaml markup. you don't need the WYSIWYG editor.
as for adding/referencing classes first you need to reference the assembly the class is located in. your core .net types (part of the BCL, base class library) are automatically included as references. then you add a using statement to the appropriate namespace. then you can instantiate the object.

There are ways to have a C# interactive window; see this question. Alternatively, you don't need to use a form, but you could also create a command-line application.
As for the second question, you can add a new class to your project and then use it in your form. There's really no additional step, except that if the namespaces are different, then it is easier if you import that namespace (via using).

Partly, yes, because you're new and using tutorials.
Partly, no, because you're working with forms, and you really don't want to hand-code those by hand.
If you just want to play with C#, and not concern yourself with forms and display, look for information on Console application. Instead of worrying about buttons and textboxes, your worst nightmare will be Console.WriteLine();
Here are some console-based C# tutorials:
C# Station tutorial
C# Yellow Book - it's a PDF. It's good.

Yes, it is exactly because you are following the video tutorials which are almost always tailored for beginners... Most of us making a living working in VS, developing WPF solutions do not even use the visual editor but instead work directly with XAML to build our UI and have very little or no code in the code behind files following the MVVM pattern.
To answer your second question, most of your classes that "do stuff" which is not directly intertwined with the UI should be in a separate class library (dll file) and should not even be referenced directly by your main UI project (in order to facilitate loose coupling) but instead accessed using some form of Dependency Injection, typically utilizing Interfaces.
The code that responds to user interaction should be in your ViewModel classess which are typically a data context for your views and these VM classes are typically using service agents which implement different Interfaces in order to use code stored in the class libraries mentioned in the previous paragraph.
Now, it is possible to just double click on a button and write all your code in that method created for you in the code behind file just like with Winforms, but just like in the Winforms world that leads to code that is hard to maintain, that is tightly coupled to your user interface and very difficult to test so try to resist that instant gratification and invest some time in learning the MVVM pattern, DI and OO design patterns which facilitate code reuse, decoupling and testability...
Hope this helps...

It really depends on what you are trying to learn. I don't think I would start off with WPF if I was using C#. I would start off with a console application to get the basics of the language down, then move down to a simple WinForms application, and finally to WPF where you started.
But yes, your questions about how the editor works is correct. It's how that platform works.

Handle navigation between several view in a WPF application

I've done several WPF application(not using MVVM) in the past and I had always to implement my own system of navigation between view(instantiate the view once, and then load in a container component, with refreshing required components of my view).
It works, but:
It's always custom, so if a new developer comes he has to learn of it how it works
I'm pretty sure that It's not the most optimized(most of things haven't been done in background worker, ...)
It's a time loss
So I was wondering if there is an official way to handle this ? I don't exactly how, but I was thinking to a navigation component, which can act a little like a tab panel, or a little like the MVC framework in asp.net, we can call a specified controller for an action and some parameters.
Maybe deactiviting bindings when they aren't in the current view

You can use DataTemplates/Styles to customize content of your control ( not only apearance, but data, cause that what you're asking for I presume)
http://msdn.microsoft.com/en-us/library/ms742521.aspx
You can have one Host control and at runtime change its appearance based on events/ states.
Like an example can have a look here:
http://code.google.com/p/svnradar/ how this program manages a appearance of Group and Flat view of repository information.
Another example:
Podder of Josh Smith
http://joshsmithonwpf.wordpress.com/2008/03/05/podder-v2-has-been-released/
Hope this helps.

You may be interested by Lakana, a lightweight (but powerful) framework that can handle for you all the navigation concerns !
Riana

Use Dependency Properties for global properties

I am new to WPF. I have been reading a lot about WPF and dependency properties. My understanding of Dependency Properties is to bind properties to XAML (XAML being the target). I have envisioned a program in which a single configuration window would control all visual elements of the rest of the program (font, font size, colors, etc).
In my first attempt, I created a separate window that would contain all the different configuration options. This failed because I was unable to figure out how to use the dependency properties in separate XAML files.
Also, the dependency properties can only be registered in a class that implements directly or indirectly the DependecyObject class. How do I know which wpf objects implement it? It appears the window does not, but I could be wrong. My second attempt was this, to register the dependencies in the top window, so the whole visual tree would have access to it. I had exceptions being thrown and the only thing I could think of was that the window does not implement to DependencyObject. (I could be mistaken, and the visual tree thing is still sort of a mystery to me. I am learning though)
So now I'm at a loss. Is what I am attempting even possible? The whole purpose of this project was to help me learn WPF and now I'm wondering if I should lower my expectations of what I can accomplish with WPF.
Edit:
What kind of exception? What are you trying to do? Could you paste some code?
public partial class MainWindow : Window {
public Color BackColor {
get { return (Color)GetValue(BackColorProperty); }
set { SetValue(BackColorProperty, value); }
}
public static readonly DependencyProperty BackColorProperty =
DependencyProperty.Register("BackColor",typeof(Color),typeof(MainWindow),
new UIPropertyMetadata(0));
It appears that Color was causing the exception. I changed it to int and no exception was thrown. So are primitive types only able to be registered?
WPF is a framework to help you bulit really good looking apps (it includes also Printing etc.) What are you trying to do? Should it be a part of Visual Tree?
Again, this project was only meant to get me to learn WPF. My idea was to create a main UI with different pages. A configuration button would bring up a window with options to change font, fontsize, background color, etc. These changes would be applied in the main UI as the user made the changes. My issue has been how do I access those dependency properties outside of the configuration class where they were registered? How do I have one window that can have slider and combo boxes, and any other class can access those configuration settings?
Put simply, I would like that a single configuration (fonts and colors) be somehow inherited by all UIs. And that that configuration can be changed and seen by the user.

Also, the dependency properties can only be registered in a class that implements directly or indeirectly the DependecyObject class. How do I know which wpf objects implement it? It appears the window does not, but I could be wrong.
http://msdn.microsoft.com/en-us/library/system.windows.window.aspx
look at the Inheritance Hierarchy it does implement DependecyObject
My second attempt was this, to register the dependencies in the top window, so the whole visual tree would have access to it. I had exceptions being thrown and the only thing I could thing of was that the window does not implement to DependencyObject.
What kind of exception? What are you trying to do? Could you paste some code?
So now I'm at a loss. Is what I am attempting even possible? The whole purpose of this project was to help me learn wpf and now I'm wondering if I should lower my expectations of what I can accomplish with wpf.
WPF is a framework to help you bulit really good looking apps (it includes also Printing etc.) What are you trying to do? Should it be a part of Visual Tree?

We cannot tackle here the big task of learning a whole new framework and designing your whole program. That will take time. It can be daunting but stick with it.
As for your exception, the problem is that the mysterious:
UIPropertyMetadata(0)
is actually providing the default value for the dependency property and this value must match the type specified in the second argument to Register. Since 0 is an integer and your property is a Color the dependency property subsystem throws an exception. Instead you can use:
UIPropertyMetadata(new Color())
or any other color as the default.

Dependency properties are a newer design specifically created for WPF. One of the problems they solve is to create faster resolves of the property values because they don't use older, slower, techniques (Read up on why they were created).
They are hard at first, to understand, because it's not exactly clear why they are needed when there is support for the Interface named INotifyPropertyChanged. But one main reason (among others) is that if you implement a DependencyProperty correctly, you will be able to change the design time property values of that property in the property window! Now this is a very cool thing to do because you can very easily set all of your default properties that way.
Doing this for the sake of design time property editing allows you to learn a lot more about DPs and why they are used. In fact, some prefer them everywhere, as they just are not that hard to code up.
DPs are also used when creating custom controls using the "Generic" folder method. This is how Microsoft themselves create all their controls.
There are some caveats to be aware of when using them. You cannot see the design time properties of a DPs until that particular control is contained by something else. In other words a UserControl with DPs will not show those Dps in the UserControl design. They will; however, show up in the control that contains that user control.
DPs bring maximum control using Metadata, PropertyChanged callbacks, default values, and Cohersion and other techniques which give you 100% control of what they contain. The DP is the ultimate in property control.
Keep scouring the internet as there are tons of articles out there on the topic.