iGoogle, youGoogle

I have to admit, I'm a bit of a Google fan. Not that I have any particular feelings about the company as such. I think their famous philosophy (do no evil) went out the window the minute they went public. It's just that they seem to come up with very interesting and useful tools. I particularly like iGoogle and the way it allows me to tailor my own little collection of web gadgets. Every morning I come to work I can browse through all the news, blog RSS feeds, weather and calendar at a single glance. And there's no noise, it's only the news and blogs that interest me. Now I'm looking for ways to customize my own searches. Narrowing the search to selected sites is easy with Google Custom Search Engine. It's the results that I don't like, or rather the way they are presented. For example, suppose I narrow a search to include three sites, I wish I could then present the results in three columns. Maybe I can. I just haven't figured it out yet.

If anyone out there is looking for a mashup that will make millions, this is it. Information is power, but the problem is there's too much information available. Google search is loosing its foothold, because it simply relies on showing the most likely result first. That's rarely what you're looking for these days. Anyone who can come up with a superior way to filter information from the Internet is destined for greatness.

WPF 3D support

I've been involved with 3D graphics more or less my entire work career. When I learned that WPF had 3D support, I was naturally excited to see what that meant, and especially what kind of graphical objects it supported. Needless to say I was somewhat disappointed to learn that there is the Triangle and, um..., that's it. The Triangle!?! No sphere, mesh, cylinder. I made my views known to an instructor at a WPF course I was attending and he protested my disappointment arguing that WPF's 3D support wasn't meant to compete with high-end CAD solutions. According to him it was targeted for the use of static 3D models á la The North Face kiosk. OK, I can see that. You create a 3D model with third-party 3D modeling app, export to XAML and use the models as resources. But why couldn't the 3D support be more advanced. It would be a easy to create an application like Google SketchUp, which by the way is a fantastic app in its own niche, whatever that is.

I'm sure the WPF 3D support will evolve and I can't wait to see what they come up with. In the mean time I'll have to settle for our old Win32 code for proper 3D.

WPF-Win32 interop with HwndSource

I was given a task to design a new GUI using WPF, and then interface that with some legacy Win32 code. The challenge of course was the interop between the native side and the managed side. I looked up some sample code from MSDN and a couple of books, and thought I was well on my way. The idea was to host WPF controls in an MFC CDialog. Switching the MFC project into managed code was not an option, so I decided to create a mixed-mode MFC Extension DLL. This would allow me to wrap the WPF controls inside a CWnd, which I would then be able to use in a native CDialog. WPF interop provides a HwndSource class for hosting WPF content in a HWND window. I actually learned this technique from Nishant Sivakumar's book C++/CLI in Action.



Everything worked beautifully until I tried to write text into a WPF TextBox. Nothing happened. I was able to delete characters by pressing Del or Backspace. HwndSource has its own window procedure and is supposed to handle message dispatching so I was baffled. Little testing showed that the TextBox was firing KeyDown events but not TextInput events. KeyDown is equivalent to WM_KEYDOWN and TextInput is equivalent to WM_CHAR. Somewhere along the way the WM_CHAR messages were lost. Turns out the standard dialog message loop calls IsDialogMessage, which "eats up" WM_CHAR messages. Had I been using a modeless dialog or a non-dialog window, everything would have worked. MS dev support suspected this might be a flaw in the WPF interop and might be fixed later.

And now the workaround. HwndSource allows you to add hooks to the event handler. The following shows an event hook that will ensure WM_CHAR messages are dispatched to the WPF side.

IntPtr ChildHwndSourceHook(IntPtr hwnd, int msg,
    IntPtr wParam, IntPtr lParam, bool% handled)
{
    if(msg == WM_GETDLGCODE)
    {
        handled = true;

        return IntPtr(DLGC_WANTCHARS);
    }

    return IntPtr(0);
}

 ...

HwndSource^ source = gcnew
             HwndSource(sourceParams);
source->AddHook(gcnew  
    HwndSourceHook(ChildHwndSourceHook));

Thanks to Chango for the workaround.

XAML readability

I've recently started learning Windows Presentation Foundation development. WPF presents an entirely new way of defining the UI and its behavior, eXtensible Application Markup Language or XAML (pronounced 'zammel'). While I can see the benefits of using a markup language for defining the UI, my first thought after having written a few test programs was how horrible XAML was to read and write. When writing procedural code I've always been very particular about writing code that is extremely readable. Well, not always. Like most developers, I've learned this the hard way. Once you've spent hours trying to figure out what some piece of code is doing, you start to appreciate well-formed code. Also, I haven't really worked with HTML or XML or any other markup language.

So the obvious answer was to use a tool like Microsoft Expression Blend. After having tried it I remembered a web developer who got angry with me when I asked why he chose to write HTML by hand instead of using a tool. I became a target of a 5-minute rant about the terrible HTML code various tools produced. Now I found myself disagreeing with Expression Blend on how to best format the XAML code. Since then I've adopted a middle ground approach, I use Blend to design the UI, then go through the code and fix what I think is not particularly well coded. I wouldn't dream of coding things like animations by hand. Still, coming from procedural code background, I feel slightly out of place when coding a UI partly in XAML and partly in C#. Yet all the magical things I can do with WPF mean I can't stay away from it. I'm curious to see if the process starts to feel more natural in the future. One thing I can promise, though. I will never, ever like the way XAML looks.