ShawnVN's Blog

ColorComb: Yet Another Color-Picker Dialog for WPF

2006-12-05T08:08:00Z

WPF v1 doesn't include a color-picker dialog (or a font dialog). A variety of SDK samples and community samples will undoubtedly fill this void. That's ok with me -- I've never been happy with the traditional Windows color-picker UI, anyway. I can never find the color I have in mind, looking at this flattened-out-color-wheel-with-dingy-grey-bottom......(read more)

AutoClaimsFX

2006-05-31T11:07:00Z

In celebration of WinFX Beta2, I've attempted to recreate the Tablet PC SDK's beloved AutoClaims sample in WPF.

This sample demonstrates:

InkCanvas
- collecting ink in multiple transparent layers, over an Image resource
- databinding for Strokes
- DefaultDrawingAttributes defined in static resources
- animated Opacity and ZIndex properties for smooth transitions among layers

TextBox.InputScope
- defines a pattern to coerce Tablet Input Panel handwriting recognition for the Year (YYYY) field

Scrolling and resizing
- relative layout techniques
- ScrollViewer around the Image and InkCanvas elements

...all in 100% pure XAML!

http://www.windojitsu.com/blog/autoclaimsfx.html

Ok, admittedly it probably would've been easier to code some of those lengthy EventTriggers for managing the layers in C#. And I'm a little bummed to discover than I can't set Panel.ZIndex in partial trust (else you'd be running this app in your browser right now, not reading about it).

Still, it's a fun exercise in what can be done with InkCanvas and XAML, with so few lines of code compared to our WinForms platform. You really have to compile and run the mundane old WinForms version, and peruse the code, to appreciate this WPF rendition.

Have fun!

ScrollViewer for Lefties

2006-03-09T08:09:00Z

Josh says “Windows Presentation Foundation (aka WPF, aka Avalon) is the best thing to happen to Tablet PC's.”

Josh, I couldn't have said that better... well done! (We're trying hard to live up to your expectations, anyway. :-)

This reminds me -- at a recent talk, I happened to mention (to a group of Tablet PC developers) how ScrollViewer could be re-styled to align the scrollbar on the left, for left-handed users. The response was quite enthusiastic! Here's the XAML...

http://www.windojitsu.com/blog/leftiescrollviewer.html

WinFX Ink: Fun with VisualBrush

2006-02-03T07:51:00Z

Just in case anybody who reads this doesn't read Petzold... http://www.windojitsu.com/blog/inkcanvasvsvisualbrush.html

WinFX Nov CTP: Fun with InkCanvas

2005-11-22T06:09:00Z

Here's a fun little InkCanvas sample app, in celebration of the Nov CTP release of WinFX... yeah that's right, it's tic-tac-toe. What? This ain't rocket science. (It does, however, include source code for a very, very simple handwriting recognition engine. :-)

http://www.windojitsu.com/blog/tictactoefx.html

Here's the URL to launch the game: http://www.windojitsu.com/tictactoefx/tictactoefx.application

New Tablet PC Team Blog Online!

2005-08-05T07:33:00Z

New Tablet PC Team blog is up on blogs.technet.com...

http://www.windojitsu.com/blog/tabletblogs.html

Physics Illustrator Hints

2005-05-22T22:41:00Z

I've never really blogged much about Physics Illustrator -- the little animated shape-reco funlet for Tablet PC, inspired by research from MIT, that my homie Peter Gruenbaum and I wrote at Leszynski Group.

But some mates of mine asked me about it last night, and I googled it... whoa boy! I've never seen such love and praise written about any piece of code I've touched. Here are some hints, along with a few PI downloads, worth perhaps a few extra hours of fun...

http://www.windojitsu.com/blog/physicsillustratorhints.html

A Bug Story

2005-01-13T23:42:00Z

http://www.windojitsu.com/blog/bugstory.html

Discuss...

Copy Constructors vs ICloneable -- Redux

2004-05-21T22:24:00Z

Back in 2002, I wrote an article for ONDotNet.com, about .NET's copying, cloning, and marshalling semantics. I suggested that the role of C++ style copy constructors was diminished, in the face of ICloneable. Boy, was I wrong...

http://www.windojitsu.com/blog/copyctorvsicloneable.html

Assembly Versioning Code of Ethics (or: Dipping Your Toes in the Warm, Gentle Waters of Code-Gen)

2003-09-17T08:18:00Z

Prompted by an email on the dotnet-clr list, I took a moment to write down my Assembly Versioning Code of Ethics. These rules are not enforced by .NET or the CLR in any way -- but I think I speak for virtuous developers everywhere when I say:

I. Thou shalt bump at least the "minor" field, when making a change that might affect existing client code.

II. Thou shalt bump at least the "revision" field, when making any other change, whatsoever.

I hate to make an example out of anyone, but a certain SDK team at MS has broken both of these simple commandments over the past 18 months, and each time it's caused quite a lot of frustration.

Post RTM, the Tablet PC team has published one additional point-release of their SDK. They bumped the version number on the Microsoft.Ink.dll assembly (the managed wrapper for the Tablet API) from v1.0.2201.0 to v1.0.2201.2. Now, I don't know what happened to the intervening 2201.1 release, but still, the small hop from 2201.0 to 2201.2 certainly looks like a innocuous little bug-fix patch, right?

But no -- they've added IDisposable implementations to about half a dozen of the most heavily-used classes, and updated the documentation to imply that if we don't call Dispose() then our apps will leak -- that's a breaking change, darnnit!

Prior to the RTM release of the SDK, they were guilty of the second sin, as well: distributing multiple versions of the assembly, all under the v1.0.2201.0 label. It was unfeasibly difficult to distinguish between them "in the field" (eg: on a coworker's misbehaving test box). These doppelganger assemblies were just internal alpha and/or beta releases, but still, such needless confusion -- why?

I know why. In fact, I'm guessing this story sounds painfully familiar to a lot of readers out there. The problem is human: it's a royal p.i.t.a. for developers to remember to bump the revision number, by hand, with each build they send off to the QA department. In the unmanaged world, binaries were (usually) not signed, and so details like version-info could be patched up in the very last build stages, by setup/integration engineers whose jobs it is to think about these things. Versioning is too important to rely on 100% unfailing compliance from 100% of all developers on your team.

The good news: with just five minutes of effort, you can automate this problem out of existence!

I've become fond of auto-generating an AssemblyVersion.cs file, pre-build, with the low-order 32 bits of the version number (the build- and revision-fields) based loosely on the current date and time.

For example: if I released a new product right now, I might stamp it v1.0.2003.916... Or maybe even v1.0.2003.9169 -- where the last digit (9) is computed something like (10*DateTime.Now.Hour/24). We only have 16 bits per field to work with, so we mustn't go crazy trying to squeeze in a full-
fidelity timestamp -- it won't happen, and it's not worth sacrificing the readability of the build-date in the version.

Some might be tempted to go further down the "version == build-time" road, eg: v2003.9.16.2315... but that doesn't easily let one release, say, a new security patch for a product that's one or more revs past its prime.

Why not? In .NET, version numbers are comparable (in the System.IComparable sense) so it's not cool to release a new patch for last year's code, which compares as anywhere close to the same patch for the current generation product. This is not just academic: someday, you or your users may wish to apply binding-redirect policies to your software, based on declared ranges of version numbers! Reserving the high-order fields in the version number to represent a logical product release is a huge help, in that case.

Besides, there's an alternative available: If you really want to stamp your assemblies with a human-readable, full-fidelity build timestamp, check out the AssemblyInformationalVersion attribute, which allows you to supply a whole string, of your own devising (eg: DateTime.Now.ToString() ;-).

Here's the X-Code .NET template I use to generate an AssemblyVersion.cs file, for all my C# projects. (This technique, if not the exact template code, should be easily portable to CodeSmith or other template-based preprocessors.) The end result? I sleep soundly at night, knowing that my build environment will automatically and unfailingly increment my assembly version number, every few hours.

<%
var now:DateTime = DateTime.Now;
var build:short = (short)(now.Year);
var revision:short = (short)(now.Month*1000 + now.Day*10 + now.Hour*10/24);
%>

[assembly: System.Reflection.AssemblyVersion(
 "<%= major %>.<%= minor %>.<%= build %>.<%= revision %>"
 )]

VS.NET Tip of the Day: Reusing C# Source Code Across Multiple Assemblies

2003-07-23T00:34:00Z

I'm surprised by how many people don't know this trick... but equally surprised by how obscure the UI is.

The Problem

Let's say you have a clever little bit of C# code you'd like to reuse, but it's something too trivial to warrant its building, supporting, and maintaining its own assembly. Or perhaps the code is something proptrietary, and you'd like to obfuscate it as fully as possible -- which usually means not exposing it in any public types. Or perhaps it's just a small set of compile-time constants that you'd like to bring into multiple assemblies.

As a trivially simple example, perhaps you get tired of specifying the same AssemblyCompany and AssemblyCopyright strings, over and over again, in all your projects? Wouldn't it be nice to have a little two-line C# file tucked away somewhere, and include it by reference in all your projects?

[assembly: System.Reflection.AssemblyCompany("Arithex.com")]
[assembly: System.Reflection.AssemblyCopyright("© 2003 Shawn A. Van Ness. All rights reserved.")]

With C++ this is trivial -- you create a header file, and #include it from wherever you like. But C# doesn't have a #include directive. Or does it?

The Solution

No, it doesn't (sorry to tease ;-). But Visual Studio .NET does offer a way to bring in C# code from a source file that's nowhere near the rest of the source files in your project directory -- it's not intra-file lexicographic inclusion, as in C++, but every C# source file can see every other C# source file in the build, so in practice there's not much difference!

Unfortunately, the UI to accomplish this task is pretty obscure -- which is probably why I run into so few developers who know about it. It's so obscure, in fact, that I often find it easier to close VS and hack the .csproj file manually. Here's what a <File> element might look like, for a C# project file (a .csproj file) that references a shared definition for my hypothetical AssemblyCompany and AssemblyCopyright strings, above:

   <File
      RelPath = "AssemblyCompanyAndCopyright.cs"
      Link = "..\..\AssemblyCompanyAndCopyright.cs"
      SubType = "Code"
      BuildAction = "Compile"
   />

Note that "RelPath" attribute is not, as you might think, a relative path to the file. That would make sense! Rather, it's the relative path of where the node will appear in the Solution Explorer treeview. (This is the same "RelPath" attribute that you see on every other file in your C# project.) The "Link" attribute is the interesting one -- that's the relative path to the actual file (relative to the .csproj file). In Solution Explorer, the "linked' file will appear with an Explorer-style shortcut arrow emblazoned over its icon.

If you have some trepidation about hacking up your .csproj files, or if you absolutely, positively insist on using a mouse... right-click your project in Solutions Explorer, and select Add Existing Item. Browse to your shared C# source file, then click the unnoticeable little dropdown arrow next to the Open button. See the ctxmenu item entitled "Link File"? That's your man.

The Catch

(There's always a catch.) For anything more complex than assembly-level attributes, one must think carefully about duplicating C# code across multiple assemblies. Consider the following hypothetical SharedConstants.cs file...

using System;
namespace MyCompany {
internal class SharedConstants {

    public const string Hello = "Hello";
    public const string World = "World";
    }
}

This will produce a new, different type named MyCompany.SharedConstants in each and every assembly you "include" it in. If the constants are large, or if the sanctity of SharedConstants' type-identity is important to you (imagine, perhaps, defining an enum this way, then later developing methods and properties which attempt to pass parameters of that type across assembly boundaries) then this approach may be undesirable -- or it may flat out break.

In that case, your only real option is to build a shared assembly which defines the constants (or enumeration values, etc), then ref that assembly in your other projects. And that is, of course, what the founding fathers of .NET intended.

Back from Japan...

2003-07-01T00:38:00Z

Just got back from a week-long training gig in Tokyo... Our newly developed class on Developing Tablet PC applications in C# has finally started to mature -- it's good stuff.

http://tabletpctraining.com/

But delivering it to an audience that, for the most part, doesn't speak English (I had a team of interpreters helping me out) and who are using Japanese VS 7.0 on Japanese XP... whoa. What an experience! Those interpreters were amazing. Truly talented souls... I'm sure they're underpaid.

As for me? I don't speak a word of Japanese. Kanjii is like Greek... err, actually, Greek is much more familiar to me. But as it happens, almost all of the keyboard shortcuts are the same on Japanese XP/VS, as in English! And those of you who know me, know how I work -- I don't do anything, without I memorize a keyboard shortcut.

So. Jet-lag notwithstanding, I was up all night before the first day of class, back-converting all our labs' project files from VS 7.1 to 7.0. Decompiling our helper components with ILDasm v1.1, hacking all the refs back from 1.0.5000 to 1.0.3300, then rebuiding with ILAsm v1.0. Damn, do I love .NET...!

And speaking of underpaid interpreters... I'm floored by the sheer cost of this trip! Some places in Tokyo want ¥2,000 for a cup of coffee. That's, like, US$20.00!!! And not a latte, mind you -- just a brewed cup of coffee. (I was afraid to ask for a refill.)

And economists covering the Japanese markets have the nerve to complain about deflation... umm...?!?!

NtfsDisable8dot3NameCreation is your friend

2003-06-09T21:31:00Z

http://www.google.com/search?q=NtfsDisable8dot3NameCreation

If you haven't done so already, I highly recommend setting this tweak in your registry, and rebooting.

It's cute when the dir command treats *.htm like *.html; it's devastating when the del command interprets *.res as *.resx.

Setting NtfsDisable8dot3NameCreation will supress the creation of shortnames for new files, but the only way I know of to remove shortname entries for existing files is to rename them.

for /r %I in (*) do @ren "%I" "%~nxI.no8dot3" && ren "%I.no8dot3" "%~nxI"
for /d /r %I in (*) do @ren "%I" "%~nxI.no8dot3" && ren "%I.no8dot3" "%~nxI"

But be careful -- only do this for data files, not for anything might be installed/registered software. Your registry is full of shortnames pointing into your ProgramFiles folder!

All quiet along the Toolbox front...

2003-04-24T09:03:00Z

The saga continues. Soon after I reported the terrible timing-sensitive bug in the VS automation layer, I got a friendly email from someone smarter than me, and with a microsoft.com email address. That's the kind I like..!

I've forgotten how most of this COM/OLE goo works, but this kind soul reminded me that OLE message filters (ala IMessageFilter, but not the one you're thinking of!) are the key to avoiding call-rejected errors from COM plumbing.

Code follows. Caveat emptor -- but it works for me!

using System;
using System.Runtime.InteropServices;

/*
This class implements an OLE message filter, appropriate for use with the VS automation clients.

Sample usage:

    [STAThread]
    private static void Main()
    {
        // We avoid instantiating the RCW as "new DTE()", because the both PIAs for v7.0 and v7.1 point 
        // to the same CLSID (VS 7.0's)... 
        Type latestDTE = Type.GetTypeFromProgID("VisualStudio.DTE"); //ver-indep progid
        EnvDTE.DTE dte = Activator.CreateInstance(latestDTE) as EnvDTE.DTE;

        // Register an OLE message filter to avoid "call rejected" exceptions
        MessageFilter.Register();

        // Drive the VS automation interface
        Installer1.AddToolBoxTab(dte); // or whatever

        // Unplug the message filter
        MessageFilter.Revoke();
    }
*/

class MessageFilter : IOleMessageFilter
{
    //
    // Public API

    public static void Register()
    {
        IOleMessageFilter newfilter = new MessageFilter(); 

        IOleMessageFilter oldfilter = null; 
        CoRegisterMessageFilter(newfilter, out oldfilter);
    }

    public static void Revoke()
    {
        IOleMessageFilter oldfilter = null; 
        CoRegisterMessageFilter(null, out oldfilter);
    }

    //
    // IOleMessageFilter impl
    
    int IOleMessageFilter.HandleInComingCall(int dwCallType, System.IntPtr hTaskCaller, int dwTickCount, System.IntPtr lpInterfaceInfo) 
    {
        System.Diagnostics.Debug.WriteLine("IOleMessageFilter::HandleInComingCall");

        return 0; //SERVERCALL_ISHANDLED
    }

    int IOleMessageFilter.RetryRejectedCall(System.IntPtr hTaskCallee, int dwTickCount, int dwRejectType)
    {
        System.Diagnostics.Debug.WriteLine("IOleMessageFilter::RetryRejectedCall");

        if (dwRejectType == 2 ) //SERVERCALL_RETRYLATER
        {
            System.Diagnostics.Debug.WriteLine("Retry call later");
            return 99; //retry immediately if return >=0 & <100
        }
        return -1; //cancel call
    }

    int IOleMessageFilter.MessagePending(System.IntPtr hTaskCallee, int dwTickCount, int dwPendingType)
    {
        System.Diagnostics.Debug.WriteLine("IOleMessageFilter::MessagePending");

        return 2; //PENDINGMSG_WAITDEFPROCESS 
    }

    //
    // Implementation

    [DllImport("Ole32.dll")]
    private static extern int CoRegisterMessageFilter(IOleMessageFilter newfilter, out IOleMessageFilter oldfilter);
}

[ComImport(), Guid("00000016-0000-0000-C000-000000000046"),    
InterfaceTypeAttribute(ComInterfaceType.InterfaceIsIUnknown)]
interface IOleMessageFilter // deliberately renamed to avoid confusion w/ System.Windows.Forms.IMessageFilter
{
    [PreserveSig]
    int HandleInComingCall( 
        int dwCallType, 
        IntPtr hTaskCaller, 
        int dwTickCount, 
        IntPtr lpInterfaceInfo);

    [PreserveSig]
    int RetryRejectedCall( 
        IntPtr hTaskCallee, 
        int dwTickCount,
        int dwRejectType);

    [PreserveSig]
    int MessagePending( 
        IntPtr hTaskCallee, 
        int dwTickCount,
        int dwPendingType);
}

Revenge of the Toolbox: Part Deux

2003-04-16T02:53:00Z

Everybody has been following along with my little toolbox saga, right?

It just doesn't let up. Today it threw me another curve -- a timing bug! -- apparently it's failing in our test lab, on slow machines (think: sub-900 MHz laptops, w/ slow busses).

Sometimes I get a "call was rejected by the callee" exception, sometimes just silent failure (no exceptions, but no new toolbox items either). When the exceptions do occur, it's never in a predictable spot (just one of the several calls in to VS).

The bug seems to manifest on both VS 7.0 and 7.1, but I'm not 100% sure of that. I managed to repro on my high-end dev box, by cranking my SETI@Home client's process priority up to "high". ;-)

Sprinkling around a few Thread.Sleep calls seems to fix the problem nicely... well, not "nicely", but what else can I do?

        // Get DTE from version-indep progid (points to newest)
        Type latestDTE = Type.GetTypeFromProgID("VisualStudio.DTE");
        EnvDTE.DTE dte = Activator.CreateInstance(latestDTE) as
            EnvDTE.DTE;

        // Repeat attempt to drive VS, with ever-increasing handicap
        for (int delayFudge=100; delayFudge < 5000; delayFudge += 1000)
        {
            try
            {
                AddToolboxItems(dte,delayFudge);
                break; // exit loop
            }
            catch (Exception ex)
            {
                Debug.WriteLine(ex.Message + "\nTrying again...");
            }
        }

At what point do I just give up, and look for a new job?