We Keep Coding

How to bind a Dependency Property in a Viewmodel of a Custom Control

I hope my Title is not too confusing.
I'm new in MVVM so sorry for some missunderstandings on my side in advance.
I have a Window A in which I put a Custom Control B. B has a ViewModel VM.
in VM i created a Custom Dependenty Property DP.
So no i want to bind DP on a Property in my Window A.
My question is now how do i do that?
Is it even possible?
Or do i have to put my Dependency Property and all other logic in the code behind in this case?
I hope someone can help me and i provided enough information to understand my problem...

You're having issues because you created a ViewModel for your UserConrol. Think about it--does a TextBox have a TextBoxViewModel? No.
Your UserControl should be designed like any other control. Expose properties on its surface that people bind to. You can bind to those properties within the UserControl as needed. And use your codebehind for whatever UI logic you need.
Business logic shouldn't be scoped within a UserControl, so pull any of that out.

inheriting object from another class

So currently I have a RadAutocomplete box. I am able to call that object in the
public MainWindow()
But I want to be able to call it in my viewmodel. If I may get tips and suggestions Would be great.

Never in WPF create UI elements, like in your case telerik objects, from view model.
If you do so, you loose benefits of MVVM.
View model is for binding between UI and business logic itself. You have to define telerik oject in XAML and show/hide it based on model view property.

WPF - MVVM start action when view is opened

I am writing a little piece of MVVM for training to wrap my head around the feature.
I have created a Model for my Image model class so that each Image item contains an ID, Name, Link and other stuff like height and width etc.
I have created a View as well to show the data. Nothing fancy. Just a simple ItemsControl that gets put inside my MainWindow Grid on startup.
I am now creating the ImageViewModel class which is where I am stumbling a little.
I have defined that class as such - not sure if I did that correctly:
public class ImageViewModel : Screen
I have also written some code that the software should perform to go get the data from the net and just parse stuff and retrieve a new Image item for each available new item on the net. the code should work fine as it worked perfectly when i coded this without the MVVM feature.
My issue is that i do not know how to make the action (called public void FindNewImages) launch the second the View is loaded inside my MainWindow grid on startup... How can I achieve this?

It depends on how you've wired up your view and view models. It sounds like you may be doing view first, where your view model is a resource of the view. In which case, you can invoke your FindNewImages method in the constructor of the view model.
I would however strongly recommend that you use an MVVM framework, such as Caliburn.Micro which provides screen life cycle. In this case, you could use a view model first approach, and invoke your method in the OnActivate method of the Screen type provided by Caliburn.Micro.

MVVM: Convert code-behind to XAML

I've got an AllTopicsViewModel and its got a property ExerciseVM which is an AllExerciseViewModel, since I want to be able to refresh the AllExerciseViewModel of an ExerciseView so I am doing it like this (not even sure if it violates MVVM, pls. tell me). Well, I want to convert the 2 lines following the InitializeComponent to XAML but not sure how, can anyone help me out?
public MainWindow()
{
InitializeComponent();
AllTopicsViewModel vm = (AllTopicsViewModel)topicsView.DataContext;
vm.ExerciseVM = (AllExercisesViewModel)exercisesView.DataContext;
}

Yes, this is a misconception, according to the idea of MVVM.
Ideally, your View's codebehind (view.xaml.cs) contains nothing more than the auto generated code. Your view only accesses the ViewModel via WPF's data binding mechanisms. Because data binding via WPF is a loose coupling between the binding view and the bound-to ViewModel, you achieve the seperation that drives people to use MVVM.
You are retrieving the ViewModel in the Views codebehind from your control's DataContexts. With this, you create a strong reference between View and ViewModel. So, to help you with your question: You should think about what you are trying to to do with your ViewModel in the View's codebehind and how you can do it differently, either in the view's XAML or in the ViewModel's code itself.
If you like, post the complete MainWindow() class for some advice...
EDIT:
Ok, so its just about setting the child ViewModel on the parent ViewModel. The parent ViewModel AllTopicsViewModel should be responsible for setting its own ExerciseVM on initialization. This is not the View's job. the parent viewModel should assemble the data from one or more models and then create the child view models which the view consumes. Does that make sense for you?

Should I write classes for WPF controls?

I have a grid which I call let's say FooHistory. Now I need plenty of functionality related to that so I go ahead and I create a FooHistory class. Now I have a FooHistory class and a control.
In my MainWindow constructor I create a new instance of this class and pass the instance of this (i.e. the MainWindow) to the FooHistory class sort of like dependency injection. Then later when the FooHistory class wants to interact with the FooHistory control, I do things like this.mainWindow.FooHistory.Items.Add(...).
My question is that is this the recommended way to write WPF applications or am I missing some fundamental approaches?

We use for our programs the MVVM approach. While the details may differ from program to program MVVM is usually build with 3 main parts.
Model:
This is you data object. This may be business data like
class Account
{
string Name {get;set;}
string Address {get;set;
}
but can also be UI data like:
class Window
{
Point Position {get;set;}
Size Size {get;set;}
}
These objects are for holding data, nothing more. No events, no commands no methods (Thats one point where different interpretation of MVVM differ).
ViewModel:
This is to wrap the model and provide logic around the underlying model. This class is also used to convert a business model property into a view understandable property.
class AccountViewModel
{
public AccountViewModel(Account aWrappedModel)
{
}
string Name {get {return Model.Name;} }
AddressObject Address { get{ return new AddressObject( Model.Address ); }
}
View:
Is the wpf part this can be user controls, custom controls, windows, datatemplates etc.
Despite a common believe, its fine to have code behind for view otherwise you have to bend over backwords just because you heard that the view isn't allowed to have code.
The usual approach now is to create a model, one or more viewmodels and set these viewmodels as DataContext in your view. Sometimes you need a DataTemplate to display the given data, like a DataTemplate for our AccountViewModel.
<DataTemplate DataType="{x:Type AccountViewModel}">
<StackPanel>
<TextBox Text="{Binding Name}/>
<Button Content="Save" Command="{Binding SaveAccount}"/>
</StackPanel>
</DataTemplate>
This design makes heavy use of Databinding which is fundamental for MVVM and works quite nicely. Of course a couple of problems can arise like: How to handle Collection with models? How to handle events in the viewmodels coming from the ui? How to store my data?
But for these you find many resources here and in the web. But this answer should give you a rough overview of how i and alot other people work with WPF.

if most of your functionality is presentation-logic,
you can create a user control (by subclassing UserControl), and have a pair of .xaml and .xaml.cs files,
and put your presentation logic in the .xaml.cs file.
if most of the FooHistory class functionality is business-logic (or anything other than presentation), it's worthwhile to separate the FooHistory control from the FooHistory class, but in this case perhaps it's better to define an interface for the control, and pass the FooHistory instsance a reference to the control using this interface.
this way your FooHistory class needn't know anything about presentation - doesn't even need to know that it's WPF.
if you can avoid passing a tree of controls (such as SomeWindow.ParentControl.ChildControl.Items), it would make your life easier.

What you've described sounds like some kind of Model-View-Presenter pattern, a variant of MVC. As it is definitely a good pattern, especially for ASP.NET and WinForms, it doesn't utilise some core concepts of WPF.
Things you're missing are called Data Binding and Commands. On top of that features a new variant of MVC evolved - Model-View-ViewModel (MVVM), sometimes called Presentation Model. Roughly explained:
Your Window is called a View.
Youd Busines Logic is encapsulated in a Model.
You create a ViewModel class that exposes some properties which are View-specific representation of the Model. VM should also implement INotifyPropertyChanged to provide a way of notifying the UI about data changes. You expose operations the same way - by a property of type ICommand.
In View's constructor you write something like this.DataContext = new ViewModel()
Then you bind your View controls properties and ViewModel using {Binding PropName} syntax.
You might also want to check out some frameworks for MVVM like Prism, MVVM Light.
Here is some sample: http://rachel53461.wordpress.com/2011/05/08/simplemvvmexample/

Yes you can...... but there is no need to do that...........
the alternative way is.........
Make a dataset of data used in your grid......then import that whole dataset into your grid. so here no need to add items..... now you can filter,sort, add,remove or anything you want....