int64.org

.NET Framework

Alex Filo has the right idea, UniformWrapPanel

WPF’s Wrap­Panel is miss­ing a key fea­ture: the abil­ity to cre­ate ver­ti­cal columns, but still fill the max­i­mum amount of width avail­able. One less an­noy­ance in WPF, thanks to Alex Filo’s Uni­formWrap­Panel.

Databinding TextBlocks with XAML

I’ve be­come frus­trated lately with try­ing to data­bind a list of strings to a textblock. Ie, if I have:

string[] mytext = new string[] { "a", "b", "c" };

And I want the ef­fec­tive end re­sult to be:

<TextBlock>a, b, c</TextBlock>

Or maybe I want some­thing more com­plex like hy­per­links:

<TextBlock>
   <Hyperlink>a</Hyperlink>,
   <Hyperlink>b</Hyperlink>,
   <Hyperlink>c</Hyperlink>
</TextBlock>

Ba­si­cally what I’m look­ing for is a Item­sCon­trol that works on TextBlocks (or Spans, etc.), with a Sep­a­ra­tor tem­plate to in­sert those “, ” in be­tween the items.

Your first in­stinct might be to use a Stack­Panel in­stead, but Stack­Panel wasn’t made for dis­play­ing text. It might fool you ini­tially, but you quickly no­tice it doesn’t be­have any­thing like text: there’s no proper kern­ing, RTL, wrap­ping, or any­thing else the text classes were made to sup­port.

I’m pretty sur­prised that WPF doesn’t have any­thing like this, as it seems like dis­play­ing lists as text would be a com­mon enough thing for any app. Un­for­tu­nately I’m still not well versed enough in WPF to cre­ate such a cus­tom con­trol for my­self, and haven’t had a whole lot of time to in­ves­ti­gate it.

Using HSL colors in WPF

One thing that has al­ways ir­ri­tated me about WPF is you’re still stuck spec­i­fy­ing col­ors in RGB. HSL just feels so much more nat­ural from a de­sign stand­point. Well, we’re not com­pletely out of luck—we’ve got markup ex­ten­sions.

So I cre­ated my own Hsl­Color and HslBrush ex­ten­sions which are fairly sim­ple to use:

<Window xmlns:e="clr-namespace:WpfExtensions"
        Background="{e:HslBrush H=300,S=50,L=75,A=80}"/>

Hue is spec­i­fied in de­grees from 0 to 360, while Sat­u­ra­tion, Light­ness, and Alpha are from 0 to 100. The pa­ra­me­ters are all dou­bles and it con­verts to scRGB be­hind the scenes, which means you ac­tu­ally get a much higher color pre­ci­sion than if you had just used the equiv­a­lent RGB hex. With Win­dows 7 hav­ing na­tive sup­port for scRGB, this will fu­ture-proof your ap­pli­ca­tion to make good use of up­com­ing mon­i­tors with Deep Color sup­port.

C#: lamer by the moment

To my dis­be­lief, you can’t in­herit from generic type pa­ra­me­ters in C#. Some­thing like this is cur­rently im­pos­si­ble:

class Foo<T> : T
{
}

It’s sad, re­ally, how Mi­crosoft con­tin­ues to focus on other crap but leaves out basic things like con­straint-based over­load res­o­lu­tion or sim­ple in­her­i­tance. And still no Spec# fea­tures.

RTM hits for SQL Server 2008, Visual Studio 2008 SP1, .NET 3.5 SP1

SQL Server 2008, Vi­sual Stu­dio 2008 SP1, and .NET 3.5 SP1 have all been RTMed!

Converting SVG to XAML

While I un­der­stand (and even agree with some of) the rea­sons be­hind Mi­crosoft rein­vent­ing the wheel and not using SVG for their WPF, I find my­self con­stantly wish­ing they at least of­fered it as a sup­ported image for­mat. There is so much SVG out there, it’s a shame to not be able to use it.

On my search for a SVG to XAML con­verter I came across a few re­ally old and out of date tools, one re­cent but still sub-par tool, and fi­nally one al­most per­fect tool: Michael Swan­son’s Adobe Il­lus­tra­tor to XAML Ex­port plu­gin.

As the name sug­gests, it is a plu­gin for Adobe Il­lus­tra­tor. It works great, but It’s a bit odd to use – by de­fault, it ex­ports to a can­vas which, for every­thing I’ve ever wanted to use a XAML image, is the wrong choice. Luck­ily it also sup­ports ex­port­ing to a Draw­ing­Brush if you hold down the right shift key when you click save in Il­lus­tra­tor.

Draw­ing­Brush isn’t my first choice of for­mat, but you can eas­ily change it into a DrawingIm­age re­source, which lets you use it just like any other Im­age­Source. To do so you just take what it spits out:

<Viewbox
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<Rectangle>
   <Rectangle.Fill>
      <DrawingBrush>
         <DrawingBrush.Drawing>
            <DrawingGroup>
               ...
            </DrawingGroup>
         </DrawingBrush.Drawing>
      </DrawingBrush>
   </Rectangle.Fill>
</Rectangle>
</Viewbox>

And move it’s root Draw­ing­Group over like so:

<ResourceDictionary
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<DrawingImage x:Key="someImage">
   <DrawingImage.Drawing>
      <DrawingGroup>
         ...
      </DrawingGroup>
   </DrawingImage.Drawing>
</DrawingImage>
</ResourceDictionary>

Now you can use it just like any other re­source:

<Image Source="{StaticResource someImage}"/>

All in all, it’s a fan­tas­ti­cally use­ful tool. If it had some form of UI to se­lect ex­port op­tions in­stead of ask­ing you to use the shift key (re­ally, wtf??), it would get an A+.

WCF is pretty neat

I haven’t worked with .NET ex­ten­sively since a lit­tle bit after 2.0 was re­leased, so when I took on a new job de­vel­op­ing with it, I had some catch­ing up to do. WCF was the easy part. In fact, I’m re­ally en­joy­ing using it. I can tell they put a lot of thought into mak­ing it scal­able.

For those that don’t know, WCF is Mi­crosoft’s new web ser­vices frame­work, meant to re­place the old Re­mot­ing stuff in .NET 2.0. It lets you worry about writ­ing code—classes and meth­ods etc., and it man­ages trans­form­ing it into SOAP and WSDL in the back­ground.

The coolest thing about WCF is the sup­port for com­pletely async de­sign. You start a data­base query, put the method call into the back­ground, and re­sume it when the data­base query is done. This al­lows the server to run thou­sands of clients in only a cou­ple threads, im­prov­ing cache and mem­ory usage greatly.

One funny thing I learned from this is that ASP.​NET has full async sup­port too, it just doesn’t get a lot of ad­ver­tis­ing for some rea­son. The one thing that an­noys me about all mod­ern web de­vel­op­ment frame­works is the lack of async sup­port mak­ing you pay for 20 servers when you should only need one, and here it was under my nose all the time. Imag­ine that!