We Keep Coding

Elegant way of exposing ItemContainerGenerator in custom control

What's the elegant way of exposing ItemContainerGenerator from custom control?
I have ItemsSource property on my custom control and I would like to access UIElement corresponding to the bound item outside of it.
I don't have access to the ItemsControl nor ItemsContainerGenerator outside of my control. Should I expose ItemsControl or ItemContainerGenerator as a property, or maybe add a method for retrieving the UIElement?
I need to show the popup near the selected item. Maybe the popup should be a part of the control then I wouldn't have to do this?

If you want to be able to access the entire child ItemsControl, create a public read-only property that returns it.
If you only want to expose the ItemContainerGenerator, create a read-only property that returns it, e.g.:
public ChildItemContainerGenerator => childControl.ItemContainerGenerator;
If it makes no sense to expose the entire ItemContainerGenerator, create a public method that uses the ItemContainerGenerator internally to perform whatever you want to.
Which option to choose all comes down to your requirements actually.

Hidden public property in WPF control

I am writing a custom control in WPF that works in this way: user sets some property which type is some class. Then, the control examines this object and generates some collection, which is to be displayed in UI via data binding.
In order for data binding to work, this collection should be a public property, but for the sake of incapsulation I do not want it to be public.
What is the best practice in such a situation?

You can use the Browsable attribute to hide property from property grid and the EditorBrowsable attribute to hide it from the XAML\CS editor. Or you can override the OnApplyTemplate method and assign your property value to the target element. You can get target element using the GetTemplateChild method.

When should I use dependency properties in WPF?

When should I use dependency properties in WPF?
They are static, so we save a lot on memory, compared to using .NET properties.
Other gains of using dependency properties over .NET properties are:
1) no need to check thread access
2) prompt a containing element to be rendered
etc...
So it seems I should ALWAYS use dependency properties in my projects where I use WPF?
Maybe for some trivial properties of helper classes here and there I could
get away with .NET properties...

Dependency Property is a broad concept to explain which might take couple of pages to write. So just to answer your main question, Dependency property is used where
You know the property is going to be the binding target i.e you are creating a user control/custom control and want property that should be binding driven.
You want automatic property change notifications (coerse and validation also).
We want value inheritance in styles,themes, parent or default value.
There is not need to create the properties on Model or ViewModel layer as dependency properties most of the time as that is not going to help much on memory saving front as most of the properties we define in model/VM will have values per instance as they will be constantly changing. Resolving Dependency property value is a burden in itself so making property dependency unnecessarily is not advisable.
Thanks

The main reason to create DependencyProperty is when you write you own WPF control.
DependencyProperties can be used as binding source and target, and can be animated.
The properties of all framework's controls are implemented as DependencyProperty, that why you can make powerful data binding in XAML.
However in most situation, like in with the MVVM pattern, you don't need dependency properties, INotifyPropertyChanged is enough.

The main difference is, that the value of a normal .NET property is read directly from a private member in your class, whereas the value of a DependencyProperty is resolved dynamically when calling the GetValue() method that is inherited from DependencyObject.
When you set a value of a dependency property it is not stored in a field of your object, but in a dictionary of keys and values provided by the base class DependencyObject. The key of an entry is the name of the property and the value is the value you want to set.
The advantages of dependency properties are
Reduced memory footprint:
It's a huge dissipation to store a field for each property when you think that over 90% of the properties of a UI control typically stay at its initial values. Dependency properties solve these problems by only store modified properties in the instance. The default values are stored once within the dependency property.
Value inheritance:
When you access a dependency property the value is resolved by using a value resolution strategy. If no local value is set, the dependency property navigates up the logical tree until it finds a value. When you set the FontSize on the root element it applies to all textblocks below except you override the value.
Change notification:
Dependency properties have a built-in change notification mechanism. By registering a callback in the property metadata you get notified, when the value of the property has been changed. This is also used by the databinding.
check the below url for more details about the magic behid it
dependency properties in WPF

CLR Property vs. Dependency Property
A CLR property reads directly from the private member of the class. The Get() and Set() methods of the class retrieve and store the values of the property.
Whereas when you set a value of a Dependency Property it is not stored in a field of your object, but in a dictionary of keys and values provided by the base class DependencyObject. The key of an entry is the name of the property and the value is the value you want to set.
Advantages of a Dependency Property
Less memory consumption
The Dependency Property stores the property only when it is altered or modified. Hence a huge amount of memory for fields are free.
Property value inheritance
It means that if no value is set for the property then it will return to the inheritance tree up to where it gets the value.
Change notification and Data Bindings
Whenever a property changes its value it provides notification in the Dependency Property using INotifyPropertyChange and also helps in data binding.
Participation in animation, styles and templates
A Dependency Property can animate, set styles using style setters and even provide templates for the control.
CallBacks
Whenever a property is changed you can have a callback invoked.
Resources
You can define a Resource for the definition of a Dependency Property in XAML.
Overriding Metadata
You can define certain behaviours of a Dependency Property using PropertyMetaData. Thus, overriding a metadata from a derived property will not require you to redefine or re-implement the entire property definition.

Perhaps you should take another look at the Dependency Properties Overview page at MSDN.
Personally, I would only ever create a DependencyProperty when I really need to. For the most part, I use normal CLR properties in data type and view model classes to bind to... this is absolutely fine, as long as I implement the INotifyPropertyChanged interface.
So for all of my usual data bindings, I use normal CLR properties. I only declare a Dependency Property in order to provide some added functionality in a UserControl.

Dependency properties are used when you want data binding in a UserControl, and is the standard method of data binding for the WPF Framework controls. DPs have slightly better binding performance, and everything is provided to you when inside a UserControl to implement them.
Otherwise, you typically use INotifyPropertyChanged for binding elsewhere, since it's easier to implement in stand-alone classes and has less overhead. As far as your original assumptions:
There is a local instance of your variable, you definitely do not save any overhead over a property since there is significant data binding logic built-in.
They must be accessed on the main thread.

What event is generate when ContentControl.Content is set?

I need to subscribe to an event for a control when ContentControl.Content is set.
Please, what event can I put in my code to set it?
I tried to use SourceUpdated and DataContextChanged, but it is not working.

From this webpage:
The strange approach to receiving notifications of changes in dependency properties involves dynamically creating both a dependency property and data binding. If you're writing a class that descends from DependencyObject, have access to an object that contains dependency properties, and need to be notified when one of those dependency properties changes, you can create a dependency property and a binding on the fly to give you the information you need.
ContentControl.Content is a dependency property.

Checkbox with both a default content values as well as one from binding

I have a a checkbox in XAML where i need the content to have a default value, lets say: "FooText", but also a binding to a field in an object, that can change.
The idea is that is that at load the checkbox should show the default content, but when an object is loaded the content should change accordingly.
Is this possible, and if so, how? I have some idea that i might be doable in a template, but since im pretty new to WPF i have no idea how to achieve the required result.
Im using the MVVM pattern.
Hope that someone might have a good idea:-D

You could use a default object for that, where you set all properties to the default value you want and then use it as DataContext.
Another thing is the TargetNullValue on Bindings. Using that you can set a default value to show if the target value of a binding is null.

It really depends on what you mean by "default value". WPF Databinding allows for a few ways to handle "default values":
FallbackValue: This allows you to specify a value if there is an issue with the databinding itself. For example, if you are binding to a property that does not exist on the viewmodel (DataContext).
TargetNullValue: This allows you to specify a value if the binding value is null, which is very possible for string values.
You can use both if you want to account for bad binding and null values, it's up to you. Either way, you should use FallbackValue often.

Create a checkboxContent property in viewmodel
set a default value to its private variable _checkboxContent = "FooText";
Bind this property to checkbox Content
When the object loads, assign the object property to checkboxContent property