WPF Dependency properties have an interesting flag that you can specify when registering property:

Specifying this flag allows property value to propagate through the parent tree. That means you can have property that will have its value synced with the parent (does not have to be immediate parent) completely automatically. There is small performance penalty for this of course, but for certain usage scenarios it is very useful.

Using this is not that straight forward since there are some rules that need to be followed to implement property with inheritable values. Here they are:

  • On parent, dependency property must be defined as attached property. You can still declare property getter/setter, but property must be attached. Here is simple declaration:
public static readonly DependencyProperty InheritedValueProperty =
   typeof(int), typeof(MyClass), new FrameworkPropertyMetadata(0, 
public static int GetInheritedValue(DependencyObject target)
   return (int)target.GetValue(InheritedValueProperty);
public static void SetInheritedValue(DependencyObject target, int value)
   target.SetValue(InheritedValueProperty, value);
public int InheritedValue
      return GetTimeSlotDuration(this);
      SetTimeSlotDuration(this, value);

  • Child objects would define their instance of the property with inherited value using AddOwner. Following is the code that goes into say MyChildClass sample class:
public static readonly DependencyProperty InheritedValueProperty;
public int InheritedValue
      return (int)GetValue(InheritedValueProperty);
      SetValue(InheritedValueProperty, value);
static MyChildClass()
   InheritedValueProperty = MyClass.InheritedValueProperty.AddOwner(typeof(MyChildClass),
      new FrameworkPropertyMetadata(0, FrameworkPropertyMetadataOptions.Inherits));

Note that property is in child class declared as standard dependency property and that it specifies Inherit in meta-data options.

With setup like this now when MyChildClass in parented to MyClass visually or logically they will share the same property value automatically.

Tagged with:

Hi everyone,

We just released new version of DotNetBar for WPF with all new Super Tab Control which includes 6 popular visual styles and 14 predefined color schemes for each tab. Here is screen shot to help you visualize this great new control:

WPF Super Tab Control

To get details on SuperTabControl functionality please click here to visit SuperTabControl information page.

Our very popular Schedule control receives very asked for functionality as well. Many of you asked us to enable customization of time slot duration in Day and Week views on calendar. This release includes support for that and more. Click here to read my previous post about this new functionality.

DotNetBar for WPF now includes total of 18 great looking controls for professional WPF applications.

Tagged with:

New version of DotNetBar for WPF 5.3 is just around corner and based on your requests we’ve included the option for fine control over the time slot size in our Schedule control. Time slots in Day and Week views by default have the 30 minute duration. This is best visible in image below:

WPF Schedule Time Slot

With new release though, you can change the time slot duration by simply setting TimeSlotDuration property. Here is how the same calendar view looks like with TimeSlotDuration is set to 10 minutes:

Schedule Control Time Slot Set To 10 Minutes

There is another new option included that goes hand in hand with time slot control; Time slot labels. Now you can set LabelTimeSlots property to true to label each time slot with its starting time like so:

Labels for Schedule Control Time Slots

Wpf-Schedule is I believe, the best WPF schedule control available and with these new features we’ve added there is even more usage scenarios it can be used for. It is reliable and tested and used every day. If you are in need of a great Schedule control you must try it out.

Tagged with:

WPF Tip: Label Word Wrap

The WPF Label control is powerful, but if you simply set Content property to a string, it will not wrap on multiple lines. What to do? Use TextBlock:

<Label >

<TextBlock TextWrapping=”Wrap”>

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi a est libero. Nulla quis purus in est suscipit fringilla. Aliquam.



Notice TextWrapping property on TextBlock which specifies that text should wrap.

And if you need to use access key in label then wrap text into the AccessText instead like so:

<Label >

<AccessText TextWrapping=”Wrap”>

_Lorem ipsum dolor sit amet, consectetur adipiscing elit.



Tagged with:

Authentic and gritty speech by Michael Jordan. Two quotes that resonated with me:

Never say never, because limits, like fears, are often just an illusion.

and this one:

There is no I in team, but there is I in win.


Rush Creates Mush

Rarely when I rush through work I am happy with what I create. Sure, sometimes if you are doing something you’ve done hundreds of times before, you can rush through it without consequences, but by large, once you rush you create mush.

If it is worth doing, it is worth doing well saying is right on money.

So why do we rush? I found myself sometimes rushing through a task just to get it done. I start looking beyond the task I am working on and just want to finish it to move to the next thing. It is usually recipe for disaster. How do you stop that? You stop it by simply recognizing that you are rushing it. Once you are aware of it, you can focus on what you are doing and keep reminding yourself to do it right. Because, cleaning up the mush is even less fun…

More often though, we rush because we are under tight deadline. Now, I love deadlines. I’d put deadlines on every-single thing if I could just because having a deadline increases greatly the probability that task will actually be completed. Rarely having no deadline resulted in exceptional results. Pressure creates diamonds you know 🙂

But, negative side-effect of deadlines is the rush. You rush to meet the deadline and start cutting corners. Best way to combat that is to either scale down what needs to be done, so it can be done right within time you have or, wait for it, just blow through the deadline to do it right.

Seriously. Rarely deadlines are that time sensitive that they can’t be moved. If life itself is not on balance deadline can be moved. But don’t just drop the ball. Explain why moving deadline will result in better outcome. Also, don’t take this as excuse to do it all the time perpetually. That’s another road that leads to the town called nowhere…

Another bad thing about rush is that work that is rushed rarely is satisfying and fulfilling as work to which you gave your best. And I think this is the most important point here. You have to enjoy the journey, the work that you do. You enjoy it by giving it your best, not by rushing it. The satisfaction of getting something done is short lived. If you have not enjoyed the act of doing you’ve lost something big.

So if you feel that rush this week to just finish something take that as sign that you should do it right instead.


When Obsession Is Necessary

When we see someone on top of their game in whatever area, sport, design, writing, whatever, we often say that he/she is natural. We think that they did not have to work hard at their craft because it comes naturally to them. That couldn’t be farther from truth. It is always hard, hard work and perhaps certainly obsession with what they do. I like following quote from article about top surfer from Hawaii Clay Marzo that I read recently:

Kai Barger, a fellow Maui surfer and the current ASP world junior champion, recently called Clay “the best out of all of us, and it’s all natural. He never had to work at it.”

But Kai is wrong. Although Clay’s body appears to be perfectly designed for the sport—he has a long torso and short legs, which gives him a low center of gravity and the ability to crouch in tight barrels—his real secret is that he’s always in the water. If Clay isn’t surfing (and the only time he’s not surfing is when there are no waves or it’s a moonless night), then he’s probably watching slow-motion videos of himself surfing, which he’s been known to study for ten hours straight.


I created TweetPow (free) as showcase of couple UI components included with DotNetBar for Windows Forms, but little app took life of its own and it has been very popular with thousands of downloads. Recently I published an update that adds some nice features that you’ve been asking for.

With this update as you move mouse over tweets, you will see the 3 small buttons displayed next to the tweet that allow you to:

  1. Reply to tweet
  2. Send direct message to author of the tweet
  3. Received notifications when author posts new updates

TweetPow Powered By DotNetBar

This 3rd option is very nice. Now you can be notified on new updates by authors you choose. The notifications will be standard Windows notifications in system tray, or if you use Growl notification system, TweetPow will display Growl notifications. Nice!

I use TweetPow every day and find it very useful. For my needs it is the best Twitter app. Well, that’s not suprising since I created it for my own usage 🙂

So, there you have it. New TweetPow, try it, you might like it. It is free.

Tagged with:

My previous post about C# losing its identity, “You Have To Know Your Identity” sparked lots of good discussion, which was my intent. There are very good comments in that post and they triggered thoughts I am trying to express in this post.

Lot of developers argued that they don’t see problems with dynamic keyword and other new language constructs since if these features are used correctly they add value.

Setting aside my initial argument about identity which I still stand by, I mostly agree with that, but that *if* was always defining characteristic. Most new language features, in any language, are not bad by themselves (except when they are just poor fit for a language), but usage makes them “good” or “bad”.

For example, in C++ we have learned that most developers can’t deal effectively with manual memory management, direct memory access and pointers. That gave raise to the managed languages like C#. Now, manual memory management is not bad, many developers use it effectively, neither is direct memory access or pointers, but how they are used, the discipline that is required when you use them, makes them source of all kinds of problems. Memory leaks, security leaks due to buffer overruns, you name it.

We learned then that we should stay away from them (i.e. invent new language) since they are “bad”.

Another very good example is SQL. At the beginning, we used SQL everywhere and directly interacted with the database. SQL was everywhere. We soon learned that we should really be working with higher level of abstraction so we moved SQL to Data Access Layer (DAL) and Object Relational Mapping (ORM) tools were born. We moved from raw SQL to higher abstraction layer since we learned that doing SQL raw everywhere, is not most effective and is error prone, i.e. “bad”.

Today we are (I am not 🙂 but have seen some very shall we say LINQ rich code) spreading LINQ everywhere and I see parallels to how we started using SQL. I am wondering whether we end up creating level of abstraction on top of it for the same reasons we did that for SQL?

The hindsight is 20/20 so perhaps upfront we cannot know what will turn out to be “bad” idea. Maybe only with years of actual (ab)use we discover these things.



We learned quickly that the most important predictor of success is determination. At first we thought it might be intelligence. Everyone likes to believe that’s what makes startups succeed. It makes a better story that a company won because its founders were so smart. The PR people and reporters who spread such stories probably believe them themselves. But while it certainly helps to be smart, it’s not the deciding factor. There are plenty of people as smart as Bill Gates who achieve nothing.

Anatomy of Determination by Paul Graham


Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!

Visit our friends!

A few highly recommended friends...

© 2009 Denis Basaric: DevComponents Blog