We Keep Coding

Why does OnDrawItem event for a ListView not affect the Design-time environment?

If I create a class and make it derive from a ListView like this...
class MyListView : ListView
{
public MyListView() : base()
{
DoubleBuffered = true;
OwnerDraw = true;
Cursor = Cursors.Hand;
Scrollable = false;
}
protected override void OnDrawItem(DrawListViewItemEventArgs e)
{
//base.OnDrawItem(e);
}
}
Then I open the design view of my windows form and add a new MyListView object then add a single item and link it to a image list. I can see that there is one item in the mylistview object. It has no effect on the object I have on my form called lv of type MyListView. When I run my app on the other hand I see exactly what I expected and there is no items listed.
Why would this effect run-time and not design-time painting?

The answer
ListViewDesigner shadows OwnerDraw property like Visible or Enabled property of control. So it just works at run-time and changing it doesn't affect design-time.
Side Note
If you take a look at source code of ListViewDesigner, you will see this property:
private bool OwnerDraw
{
get { return (bool) base.ShadowProperties["OwnerDraw"]; }
set { base.ShadowProperties["OwnerDraw"] = value; }
}
And in PreFilterProperties you will see the designer replaced the original property with this one:
PropertyDescriptor oldPropertyDescriptor = (PropertyDescriptor) properties["OwnerDraw"];
if (oldPropertyDescriptor != null)
{
properties["OwnerDraw"] = TypeDescriptor.CreateProperty(typeof(ListViewDesigner),
oldPropertyDescriptor, new Attribute[0]);
}
So it doesn't matter what View you use, it performs the default painting regardless of what you have in OnDrawItem. It's because it doesn't use OwnerDraw property at design-time. The designer shadows it. This is the same behavior which you see for Enabled or Visible property.
Workaround to enable owner-draw at run-time
As a workaround, you can register a different Designer for your derived control. This way the OwnerDraw property will work as a normal property:
[Designer(typeof(ControlDesigner))]
public class MyListView : ListView
Warning: Keep in mind, by registering a new designer for the control, you will lose the current ListViewDesigner features like its designer verbs or its smart tag (actions list) window or Column Sizing options. If you need those features, you can implement those features in a custom designer by looking into ListViewDesigner source code.

UWP InvalidCastException when using XAML databinding

Can anyone explain how XAML data binding expressions are evaluated? I have a control with a registered property, VisualState.
public CardStates VisualState
{
get
{
return (CardStates)this.GetValue(VisualStateProperty);
}
set
{
this.SetValue(VisualStateProperty, value);
}
}
public static readonly DependencyProperty VisualStateProperty = DependencyProperty.RegisterAttached("VisualStateProperty", typeof(CardStates), typeof(StateManager), new PropertyMetadata(null, (s, e) => { }));
In the xaml I attempt to bind a value to this property. State exists parent's DataContext object.
<local:CardControl VisualState="{Binding State.Value}" />
The generated code in XamlTypeInfo.g.cs looks like this
private void set_4_CardControl_VisualState(object instance, object Value)
{
var that = (global::MeetEric.UI.Controls.CardControl)instance;
that.VisualState = (global::MeetEric.ViewModels.CardStates)Value;
}
This code throws an InvalidCastException because the value of Value is a Windows.UI.Xaml.Data.Binding object.
Am I missing something obvious to enable working with data bindings? Do I need some form of converter?

Try to change typeof(StateManager) to typeof(CardControl). (at DependencyProperty.RegisterAttached)
This argument requires the owner of the DependencyProperty.

This error occurs when you try to using Binding with a regular property. In order for the binding to resolve to the right type, you need to be binding to a DependencyProperty.
As others have mentioned, your syntax is a bit off which is probably causing the problem here.
This error is certainly very cryptic. I just hit it in my own project, but as soon as I changed my property to a dependency one, it worked perfect.

Dependency Property PropertyChangedCallback exception

I have the following DependencyProperty in a custom control:
public bool HasConnection
{
get { return (bool)GetValue(HasConnectionProperty); }
set { SetValue(HasConnectionProperty, value); }
}
public static readonly DependencyProperty HasConnectionProperty =
DependencyProperty.Register(
"HasConnection",
typeof(bool),
typeof(NetworkNode),
new FrameworkPropertyMetadata(
false,
FrameworkPropertyMetadataOptions.BindsTwoWayByDefault,
new PropertyChangedCallback(HasConnectionChangedCallBack)));
private static void HasConnectionChangedCallBack(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
NetworkNode nn = (NetworkNode)d;
Ellipse el = nn.GetTemplateChild("PART_inner") as Ellipse;
if (el.PART_inner.Visibility == ...) <-- exception el is null
//..code..
}
Runs fine, but if I change the property in Properties panel of my custom control, at run time throws an exception: Object reference not set to an instance of an object.
Edit1:
Forgot to add one line of code in the post Ellipse el = nn.GetTemplateChild("PART_inner") as Ellipse;
Edit2:
Creating a BooleanToVisibilityConverter and using Binding in Generic.xaml works, but the HasConnectionChangedCallBack method is now empty/useless.
Visibility="{Binding HasConnection, Converter={StaticResource BooleanToVisibiltyConverter}, RelativeSource={RelativeSource TemplatedParent}}"
Edit3:
Found a posible fix. The property callback method is called first then the OnApplyTemplate() method, so no more exceptions thrown or error in xaml.
In OnApplyTemplate() I add
if (this.HasConnection)
PART_inner.Visibility = System.Windows.Visibility.Visible;
else
PART_inner.Visibility = System.Windows.Visibility.Hidden;

Do this
private static void HasConnectionChangedCallBack(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
if (e.NewValue == null)
return;
NetworkNode nn = (NetworkNode)d;
if (nn == null || nn.Part_inner == null )
return;
if (nn.PART_inner.Visibility == ...) <-- exception
//..code..
}

The reason for the exception is that when the property is set through the XAML parser, the content of the UserControl has not been instantiated.
The XAML parser works its way from top to bottom through the XAML. A UserControl is just a shortcut for the XAML that defines it, so, at the time when the XAML parser sets HasConnection=True on the outer control, its content has not yet been instantiated, so PART_Inner doesn't yet exist.
The solution is to define the relationship between HasConnection and whatever depends on it in the UserControl in a way that keeps the instantiation sequence in mind. For example, if PART_Inner is a UserControl, you could search for its parent of type NetworkNode in its Loaded event, so that HasConnection can be evaluated then. This is probably the solution which requires the least changes to your existing code. Leave the change handler as it is now, including the safety code, and add logic to the contained control which reads the start value from its ancestor.
Other options would be to not use a DependencyPropertyChanged callback at all, but create a Binding on the Visibility property using a RelativeSource typed FindAncestor and a BooleanToVisibilityConverter. Still another idea would be to use a Trigger.

When to render custom WPF TextBlock?

When should I be building Inlines in a TextBlock? I have a TextBlock-derived class that, when given text in a certain field, call it MyText, converts the text into a set of inlines when MyText has changed.
Whenever MyText changes, I clear the Inlines and build them, colorizing each word as needed. For this example, consider:
private void MyTextBlock_MyTextChanged(object sender, EventArgs e)
{
Inlines.Clear();
if (!string.IsNullOrEmpty(this.MyText))
{
var run = new Run();
run.Foreground = Brushes.DarkRed;
run.Text = this.MyText;
Inlines.Add(run);
}
}
This has worked very well. However, recently we placed the Control into a DataGrid, and some strange things have started happening. Apparently the DataGrid swaps out the context and for the most part this works. However, when we add or delete data from the DataGrid ItemsSource, something goes awry, and TextChanged doesn't seem like it is called (or at least not called at the same time). MyText can be one value, and the Inlines either blank or a different value.
I think that the place to build the Inlines is NOT during MyTextChanged, but maybe when the rendering of the Control starts. I've also tried when the DataContextChanged, but this does not help.
In my constructor, I have
this.myTextDescriptor = DependencyPropertyDescriptor.FromProperty(
MyTextProperty, typeof(MyTextBlock));
if (this.myTextDescriptor != null)
{
this.myTextDescriptor.AddValueChanged(this, this.MyTextBlock_MyTextChanged);
}
corresponding to a dependency property I have in the class
public string MyText
{
get { return (string)GetValue(MyTextProperty); }
set { SetValue(MyTextProperty, value); }
}
public static readonly DependencyProperty MyTextProperty =
DependencyProperty.Register("MyText", typeof(string), typeof(MyTextBlock));
private readonly DependencyPropertyDescriptor myTextDescriptor;
Update: If it is any kind of clue, the problem DataGrid cells seem to be the ones that are off-screen when the addition or removal happens. I also tried OnApplyTemplate, but that didn't help.
Update2: Perhaps a better solution might be to create bindable inlines?

DataGrids virtualize their content, so if a row is not visible it will not be loaded. That being the case, have you tried also rebuilding the inlines when the Loaded event fires?

Silverlight ScrollViewer Not Scrolling

enter code hereI have a ScrollViewer in Silverlight that is not scrolling vertically whenever I call the ScrollToVerticalOffset method from the code behind.
Basically, I have my View (UserControl) that contains the ScrollViewer. I invoke an action from my ViewModel that triggers an event in the View's code-behind that sets the VerticalOffset to a specific value.
First of all, I know this is very ugly. Ideally I wish that I could have an attachable property that I could bind to a property in my ViewModel, that, when set, would cause the VerticalOffset property (which I know is read-only) to be updated, and the ScrollViewer to scroll.
The ScrollViewer contains dynamic content. So, if the user is viewing content in the ScrollViewer, and scrolls half-way down, and then clicks on a button, new content is loaded into the ScrollViewer. The problem is that the ScrollViewer's vertical offset doesn't get reset, so the user has to scroll up to read the content. So, my solution was to be able to control the vertical offset from the ViewModel, and I have racked my brain and can't come up with a viable solution, so I am looking for someone to help, please.
By the way - I have included code from a class I put together for an attachable property. This property binds to a property in my ViewModel. When I set the property in the ViewModel, it correctly triggers the PropertyChanged callback method in this class, which then calls the ScrollToVerticalOffset method for the ScrollViewer, but the ScrollViewer still doesn't scroll.
public class ScrollViewerHelper
{
public static readonly DependencyProperty BindableOffsetProperty =
DependencyProperty.RegisterAttached("BindableOffset", typeof(double), typeof(ScrollViewerHelper),
new PropertyMetadata(OnBindableOffsetChanged));
public static double GetBindableOffset(DependencyObject d)
{
return (double)d.GetValue(BindableOffsetProperty);
}
public static void SetBindableOffset(DependencyObject d, double value)
{
d.SetValue(BindableOffsetProperty, value);
}
private static void OnBindableOffsetChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
ScrollViewer scrollViewer = d as ScrollViewer;
if (scrollViewer != null)
{
scrollViewer.ScrollToVerticalOffset((double)e.NewValue);
}
}
}

This approach is a little bit funky in my opinion, as I think of both a ScrollViewer and a VerticalScrollOffset as "View" entities that should have very little (or nothing) to do with a ViewModel. It seems like this might be forcing MVVM a little too much, and creating a lot of extra work in creating an attached dependency property and basically trying to keep a bound Offset ViewModel property in sync with the readonly VerticalScrollOffset of the ScrollViewer.
I am not exactly sure of what you are trying to achieve, but it sounds like you are trying to scroll to a specified offset when some dynamic element is added to the underlying panel of your ScrollViewer. Personally, I would just want to handle this behavior with a little bit of code in my View and forget about tying it to the ViewModel.
One really nice way to do this type of thing in Silverlight 3 is with Blend behaviors. You write a little bit of behavior code in C# and then can attach it declaratively to an element in XAML. This keeps it reusable and out of your code-behind. Your project will have to reference the System.Windows.Interactivity DLL which is part of the Blend SKD.
Here's a simple example of a simple Blend behavior you could add to a ScrollViewer which scrolls to a specified offset whenever the size of the underlying content of the ScrollViewer changes:
public class ScrollToOffsetBehavior : Behavior<ScrollViewer>
{
private FrameworkElement contentElement = null;
public static readonly DependencyProperty OffsetProperty = DependencyProperty.Register(
"Offset",
typeof(double),
typeof(ScrollToOffsetBehavior),
new PropertyMetadata(0.0));
public double Offset
{
get { return (double)GetValue(OffsetProperty); }
set { SetValue(OffsetProperty, value); }
}
protected override void OnAttached()
{
base.OnAttached();
if (this.AssociatedObject != null)
{
this.AssociatedObject.Loaded += new RoutedEventHandler(AssociatedObject_Loaded);
}
}
protected override void OnDetaching()
{
base.OnDetaching();
if (this.contentElement != null)
{
this.contentElement.SizeChanged -= contentElement_SizeChanged;
}
if (this.AssociatedObject != null)
{
this.AssociatedObject.Loaded -= AssociatedObject_Loaded;
}
}
void AssociatedObject_Loaded(object sender, RoutedEventArgs e)
{
this.contentElement = this.AssociatedObject.Content as FrameworkElement;
if (this.contentElement != null)
{
this.contentElement.SizeChanged += new SizeChangedEventHandler(contentElement_SizeChanged);
}
}
void contentElement_SizeChanged(object sender, SizeChangedEventArgs e)
{
this.AssociatedObject.ScrollToVerticalOffset(this.Offset);
}
}
You could then apply this behavior to the ScrollViewer in XAML (and specify an offset of 0 to scroll back to the top):
<ScrollViewer>
<i:Interaction.Behaviors>
<local:ScrollToOffsetBehavior Offset="0"/>
</i:Interaction.Behaviors>
...Scroll Viewer Content...
</ScrollViewer>
This would be assuming that you always want to scroll to the offset whenever the content size changes. This may not be exactly what you are looking for, but it is one example of how something like this can be done in the view using a behavior.