So I’ve decided that I wouldn’t use the computer or watch TV after I get off work until I’ve exercised. I figure that I’m either going to get into shape or this could be the last post for a while. 
I figure it’s high-time I learn Windows Presentation Foundation (WPF). I’ve been putting it off long enough. I’ve given it a couple of tries in the past and ran away screaming. I would have thought that given my experience with Windows Forms and ASP.NET the transition would be easy, but it’s actually a totally different beast. I admit that it probably seems harder than it should because I’m so good at those other technologies that I can easily talk myself out of going through all the trouble of learning a new way to do something.
I think the other main reason I’ve avoided WPF until now is that I mostly program data-driven applications—the kind that Windows Forms excels at. I viewed WPF more as a way to dazzle consumers with its fancy graphics. Getting it to just display basic buttons, menus, list views, etc… seemed like a lot of work. I also have never been fond of the way it renders text. For that and other reasons I’ve avoided it.
However, I’m seeing more and more WPF adoption these days—even in business environments. Also with the rumor that Visual Studio 2010 will have a native WPF UI, I figure if it is good enough to run Visual Studio, it is good enough for anything I would do.
One of the first exercises most Windows developers usually take on is making a clone of the standard Windows Notepad application. It’s actually a great place to start learning any new language or framework. It teaches the basics of using standard controls like the Menu and TextBox, it requires hooking events and listening for notifications, it requires IO operations to load and save files, etc…. I did the same thing when I learned Windows Forms and I’ll do it again to learn WPF. You have to start somewhere.
One of the ways I thought I would motivate myself to keep pressing forward is to give regular updates here on the blog. So I’ve posted my first bit of Notepad in WPF code. It looks like Notepad, but that’s where the similarity ends. None of the menu items actually do anything yet. Hopefully over the next couple days and weeks I’ll continue to update the code and gain some experience.
Download: notepad-v01
Asynchronous Pluggable Protocols–that’s a mouthful. I came across this last night as I was doing some research on the Windows Forms WebBrowser control. First let me explain my motivation.
I have a situation at work where we’re using the WebBrowser control to window in our own company website because we never had the time to build a native Windows Forms application. The application we wrote allows our internal users a chance to review the data submitted by users on the website. Our internal analysts are presented with a window showing the web page with the user’s entered data and some additional data in the native application to help them in their analyses. This mixing of native UI and web UI has worked fine for a while, but doing that has had some drawbacks. For one, there is resource contention between the native UI which gathers additional data for the analysts to use and the website we’re windowing in. Both share the same database resources. That also introduces some concurrency issues–again because it’s like two entirely separate processes are reading and writing to the same place (one is the native application itself and the other is the website windowed in).
Some other less concerning, but still annoying drawbacks, are that we’re taking a performance hit. Having to window in a website that makes database calls through a DMZ and remoting/webservices to a database that we have direct internal access to in the native application is silly to say the least.
So why haven’t we written a native UI? Aside from the above mentioned lack of time, the web pages that we’re windowing-in are very complex data entry forms with as many as 700 input elements. Replicating and maintaining these as both web forms and Windows forms would be a maintenance headache.
I’ve floated the idea of building a UI framework that could render our data entry forms as both HTML and as Windows controls. That’s easier said than done though. They are very different beasts and usually when you build a UI framework that targets multiple platforms, one of those platforms suffers. In this case, our forms don’t translate very well to a Windows UI. Have you every tried to put 700 text boxes on a form before? It’s not pretty.
Another option I’ve considered is to continue to use the WebBrowser control, but instead of windowing in our website, we could window in some HTML pages created in memory. This would look/behave similar to a website, but instead of actually making HTTP calls to some server, the pages would be directly served up from within the application hosting the WebBrowser control. This has the added benefit that I might be able to reuse some of the HTML code we’ve labor over in the web application.
There are plenty of places on the Internet that will show you how to set the DocumentText property of the WebBrowser control, but that’s woefully inadequate for what I need. For starters, setting just the HTML of the control doesn’t allow you to load images or linked CSS files from memory.
I then read about using the “res” protocol which allows URLs that are redirected to a resource file on the file system instead. This was encouraging because it meant that if I substituted res as the URL scheme instead of say http I could then pull additional resources from memory instead of a remote server. This is a little more difficult to do in .NET because it uses the older style Win32 resource format, but it is doable.
Unfortunately, that still falls short of what I need. I would like to get the whole browsing experience. Page-to-page navigation, images, linked CSS and script resources, postbacks, etc…. I was hoping to find a way to hook into the WebBrowser control so that it would think it’s accessing a remote server, but in actuality, everything was coming from the local process memory.
Then I read about Asynchronous Pluggable Protocols and I think I might have my answer. Based on what I’ve read on MSDN, it would seem that I could register a protocol that when processed will call my code instead of the remote server. For example, I could register the protocol “in-proc” and use it in a URL like this: in-proc://some/identifier. Then when the browser encounters the in-proc protocol and has no built in handler for it, it will ask my code to handle it. I can then do whatever processing I want for that URL, whether it’s get an image out of a resource file, generate HTML, etc…. and return the result to the WebBrowser control. At least that’s my understanding of it.
I think if I could register a custom protocol and then make sure my generated pages use that protocol instead of HTTP, I could use the WebBrowser control as a reliable and robust UI but without the overhead of doing actual network IO.
I’ll let you know how it goes.
UPDATE: I found an article on CodeProject that accomplishes most, if not all, of what I’m hoping to do.