In the era of the "classic" RadControls for ASP.NET modifying a skin required opening ~ / RadControls / [ControlName] / Skins / [SkinName] / styles.css and making the necessary changes. The new RadControls for ASP.NET AJAX (formerly known as "Prometheus") by default use skins, which are embedded in the assembly. This simplifies deployment but sacrifices customization. Or does it? Actually, making a change to an embedded skin of a RadControl for ASP.NET AJAX is quite easy, given that one keeps in mind a couple of notable things. Namely: (1) Since the embedded skin cannot be modified, the custom styles need to be placed elsewhere. For example ...

Inspired by Scott Hanselman's quest to read source code to be a better developer I decided to start a series of blog posts and write about anything which comes to my mind in the everyday encountering with THE code here at Telerik. As Scott is doing a great job with his quest I would rather focus on topics in which the distinction between right and wrong is not clear enough. I'm not talking about starting flame wars but rather talking about all the aspects and the different pros and cons of each approach. Today's topic will be about infinite loops and mostly about infinite...

Hi everyone. I'm Jordan Dimitrov from the WPF team. I'm planning to post about .Net, first with few post about WPF. My first post is about resources and themes. Recently I had a problem with resources from themes files. I tried to use DynamicResource markup extension in Style in generic.xaml (sample bellow). But it didn't work. I changed DynamicResource extension with StaticResource markup extension and now it works. But WHY DynamicResource doesn't work? Sample XAML In my generic.xaml there are two items - a style for my CustomControl1 and a resource SolidColorBrush with key brush1.     1 <ResourceDictionary     2    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"     3    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"     4    xmlns:local="clr-namespace:WpfApplication1">    ...

As you are probably aware resolution and device independence is one of the fundamental design goals of WPF. In order to achieve the desired effect the framework does not work directly with physical (device-dependent) pixels but abstracts this notion into device-independent measuring units like inches. There are two main benefits that you get from this: Automatic DPI-aware scaling Sub-pixel positioning -- WPF coordinates use floating point numbers that theoretically give you the ability to draw with higher precision than the one provided by the ordinary pixel grid. However, there is one nasty side-effect related to the fact that WPF graphics are anti-aliased by default...

A short time ago, in a land not so far away, I was back in college doing the whole evangelism thing part-time as a member of Microsoft's Student Partner program. I got a lot of exposure to some great Microsoft products and, most importantly, was able to spend a lot of time coming up with cool ways to show students how to dive head-first into .NET development. At the end of my senior year, just before leaving the Student Partner program, I had this crazy idea that I could mosey on up to Redmond and say hi to the man behind the curtain...