Mark Finkle's Weblog

Permanent Redirect

2006-03-14T00:07:00.000-05:00

I finally decided to get a host of my own. I setup a blog at www.starkravingfinkle.org. Blogger has been a great experience for me and I would recommend it to anyone. I just wanted more control and space for doing my own thing.

I am updating the FeedBurner feed, so anyone actually subscribed should get updated without any problems.

Live Clipboard & Open Laszlo

2006-03-09T00:53:00.000-05:00

Two really cool announcements this week: Ray Ozzie's Live Clipboard concept and Open Laszlo running on DHTML. I see both announcements having long term effects.

Live Clipboard is just so simple and useful, it has to get adopted, standardized and built into any serious web and non-web applications. That's right, desktop applications and OS shells should also support Live Clipboard. Users will love it. Moving data between web and desktop applications should be as simple as copy/paste.

Applications built using Open Laszlo can now be run using Flash or DHTML runtimes. So those Laszlo guys were serious after all. They have a demo running on both runtimes. Very nice. This goes a long way toward platform and runtime independence. A trend I'd like to see continue. Maybe a XUL based runtime could happen too.

IE7 Changes for MSHTML Embedding

2006-02-05T16:37:00.000-05:00

This is post is really for me more than anything else. I have been trying to find some information on what new features IE7 offers for those embedding the WebBrowser control. In the process, I also found some stuff that came out with IE6 during the WinXP SP2 timeframe.

DOCHOSTUIFLAG: New flags for navigation and redirect control. Also flags for enabling new "windowless" SELECT elements instead of the old "windowed" versions.
INTERNETFEATURELIST: This enumeration of features can out in IE6, mainly for controlling security. IE7 adds a couple new features for controlling more security stuff, tabbed browsing and builtin XMLHttpRequest. Also, it provides a way to turn off the damn navigation sounds without hacking the registry. Used with CoInternetSetFeatureEnabled and related API's.
Tabbed Browsing Developer Summary: Describes the effects on the DOM, shows how applications hosts can enable tabbed browsing shortcuts, and describes new notifications.
What's New in Internet Explorer 7: Summary of the major changes in Internet Explorer 7 of particular interest to the developers.
NewWindow3 Event: Showed up in IE6 XPSP2. Gives developers better control over handling new browser windows.
Microsoft Feeds API: An API for creating, managing, and accessing Really Simple Syndication (RSS) feeds.
Protected Mode API: Develop extensions and add-ons for Internet Explorer that can interact with the file system and registry. Includes methods to control a "Save As" dialog and save content to file.
Many URI related API's: CreateUri and IUri interface just for starters.

I came across most of this stuff by searching the MSDN site looking for "Internet Explorer 7 or later". I'll try to update this page as I find out more information.

VML, SVG and Canvas

2006-01-01T14:43:00.000-05:00

Take a couple weeks off from blogging and it's real hard to get back into it. I have been working toward a BETA at my day job, playing around with a web project at home and enjoying the end of year holidays as well.

Anyway, the web project is a web application that makes heavy use of graphics. Started building on IE with VML (Vector Markup Language). I gained experience using VML from my day job. Had no problems putting together a pretty good vector graphic editor, complete with HTML text inside shapes. The editor would be a core component in the web application. Then I started adding in support for Firefox. The plan was to abstract the VML/SVG differences and use as much common code as possible. JavaScript libraries like Prototype made lots of the work easy.

The big pain was the feature differences between VML and SVG. Here are some of the problems:

VML was built as an extension to HTML. SVG is a separate specification. It took a little time to figure out how to get SVG inside an HTML document (called Inline SVG) to work correctly. Also, I can mix HTML and VML together easily in any combination. SVG requires the use of <foreignObject> to mix in HTML and Firefox does not enable <foreignObject> by default.
Shapes in VML (<rect>, <ellipse>, etc.) support text child elements. When I reposition the shape, the text moves with it. It appears that shapes can't hold text child elements until SVG 1.2, which supports <flowPara> child elements. For now, changes to the shape must be manually mirrored to the sibling text elements.
Text in VML supports wordwrap. SVG does not and I can't believe it. Again, SVG 1.2 supports <flowPara>, but I am not sure wordwrap is part of <flowPara>. How long will it take SVG 1.2 to get implemented in Firefox, Safari and Opera?
VML supports the same level of CSS attributes as HTML. SVG does not support the same level. One attribute I could not use was 'cursor'.

My biggest problems with SVG are text related. Maybe I just don't know the right way to do it in SVG. I'm still learning.

And then there's <canvas>. It has good support in Firefox, Safari and Opera (soon). Along comes Emil Eklund with an implementation of <canvas> in IE and now I have to consider switching to <canvas> as the lowest common denominator. My biggest problem with <canvas> is text (I see a theme here). I am not sure how to handle text with <canvas>.

P2P Toolkits

2005-10-15T16:06:00.000-04:00

A while ago, I was looking for a P2P framework library that I could use in a software project. The only real P2P toolkits I found were the Java-based JXTA and the Windows XP (SP1) Peer-to-Peer API from Microsoft. Neither really worked for me. I program in C++ and wanted to support older OSes.

I was too focused on 'P2P' in my searches. It finally dawned on me that multiplayer games have to solve the same problems as a P2P client. Googling turned up several interesting toolkits:

After looking at all of them, I decided to start working with DirectPlay. It has the easiest API and hides all of the low level socket stuff from me. The biggest potential problem with DirectPlay is that it appears Microsoft is sunsetting it. I don't think it's a issue though. It's still in DirectX and will be for a while. It just won't be developed any further. At some point, when Windows XP is the oldest OS I need to support, I'll switch over to the XP Peer-to Peer API.

Improvements in User Experience

2005-09-24T14:32:00.000-04:00

Inductive UI in Office 12

By now anyone interested in software user experience has seen the video or read the articles about Microsoft Office 12 getting a complete UI makeover. For an ongoing explanation of the design rationale, you should also checkout Jensen Harris' blog. Jensen works on the Office user experience team.

Many people write-off the UI changes as merely a ploy to get customers to upgrade. In a way, I agree. Customers will upgrade because the new interfaces will make using Office easier and allow users to be more productive. Inductive UI's have been around for a while, but this is the first large-scale use in a major Microsoft product.

For those of you in the back, it's not just about the menus and toolbars (or 'Ribbon' as they are calling it). It's about why the menus are gone and why the toolbar is separated into contextual sections and chunks. I am glad Microsoft spent the time and money to research how users were interacting with Office. Since Office seems to set a UX precedent, I am hoping we see some of these new conventions trickle down into other applications as well.

Update: Jeff Atwood of Coding Horror has a post about this too.

Windows Vista User Experience Guidelines

Microsoft has also released preliminary Windows Vista UX Guidelines. Although many people are pointing to the download, few are commenting on the information contained within. Chris Pirillo does provide a nice list of nuggets he discovered while scanning the documentation. I'll point out some of my favorites:

Wizard pages: Remove front and back pages. Remove page header. Basically remove all redundant textual information.
Help on Dialogs: 1. Make labels and controls easy to comprehend, 2. Add explanatory text sections as needed, 3. Use hyperlinks to jump into Help for specific topics which may be confusing, 4. Do not use vague or general Help buttons (users don't like vague or general help).
Task dialogs: MessageBox API on steriods.

I like this release better than previous ones (Win2K and WinXP) because it seems more focused on UX and contains some rationale as well. It's not just specs for controls, layout and themes. Some sections, such as Window and Layout sections, are not included yet (it's preliminary). You also need to wade through some Aero graphics babble (I am not impressed with 'glass' for UX).

Jumping In

2005-08-05T00:27:00.000-04:00

In a rather accidental manner, I am starting up several new projects. I am really getting into Wiki's. I installed MediaWiki at work for internal collaboration and knowledge management. I decided to run it on Linux instead of Windows, so I installed Ubuntu. Wow! First time I have ever done anything with a *nix. It's fantastic. I am considering switching my home machine to Ubuntu as well.

I have made many ASP-based web sites before, but now that I had a Linux server, I thought I'd try something different. I installed Django, mainly because I have always wanted an excuse to learn Python. It was much easier to get going than ASP. I had heard the same thing about Ruby On Rails for a while, but had my doubts. Those doubts are gone.

My biggest problem now is finding the time to explore them all.

Hello XUL Runner

2005-07-30T02:35:00.000-04:00

I have been playing with XUL Runner. It feels like writing a web app, but runs on the desktop. Windows, Linux and Mac desktops. Sweet!

Other things I like:

Nice selection of widgets and layouts
XBL allows new widgets and behavior to be added.
XPCOM allows calls to JavaScript and C++ non-GUI code.
SVG support is builtin. (soon)

UI Frameworks Are Pigs

2005-07-13T00:14:00.000-04:00

Why are UI frameworks pigs? Because they don't love you back.

You know the story: You meet this new UI framework. It seems so fresh and exciting. You start spending more time together, just doing small stuff. Things are so easy, not forced or boring like with your previous frameworks. So what if it acts a little immature. Before you know it, your writing specialized controls from scratch, embedding large amounts of business logic and enjoying every minute of it. Your head over heels. Next thing you know, your crying yourself to sleep and listening to Barry Manilow.

Come on buddy! Snap out of it. UI frameworks don't love you back. They don't care about you. You need to watch out for yourself. Protect yourself. Isolate your code.

If your not ready to drop your current UI framework and switch to something else right now because it could take person-years to port, you have problems. If you have team members that love your current UI framework too much to want to change, you have problems.

They don't love you back.

The experiences above are not about me, but I have this friend...

AJAX and Rocket Science

2005-07-13T00:01:00.000-04:00

Seems I am not the only one disturbed by the FUD some groups are pushing about AJAX being very difficult to implement. This post has some good examples of how easy it can be.

Writing good, quality software is non-trivial in any language. Wizards and RAD designers do not automagically generate great software.

Scalable User Experience

2005-07-04T15:48:00.000-04:00

John Montgomery on Scalable User Experience. Although I disagree with the rocket scientist required myth, I agree with John's conclusions. I especially like this quote:

Rather than trying to replace every application model in use today with one perfect model, a better solution is to let them flourish and to connect them together so that each can do what it does best. This vision, which I'd call the "Scalable User Experience," is where Atlas begins to take application models. This team is building off three tenets (even if they don't know it):

Respect the richness of the client (whatever that is) to provide the best possible user experience

Contain complexity on the server to build on existing administration skills and infrastructure

Leave no developer behind by using existing developer skills, code, and tools

I believe that AJAX is a methodology which can help achieve scalable user experiences. I am hoping toolkits like ATLAS can help with some of the weaker aspects of web applications, mainly integration with the desktop client.

This Just In: AJAX Is Important

2005-06-28T12:55:00.000-04:00

Looks like Microsoft is getting on the AJAX bandwagon, whether they like it or not. Scoble mentions a Microsoft Javascript library named ATLAS. CNET, Microsoft Watch and Information Week posted articles about ATLAS. Charles Fitzgerald is, again, the MS guy involved. Reading the articles, I can't tell if Fitzgerald is excited about ATLAS/AJAX or just feels like its something MS needed to do to stay relevant in web development. Some quotes:

"People who do (AJAX development) are rocket scientists," Fitzgerald said. "In some ways, this papers over the mess that is JavaScript development. It's easy-to-build 'spaghetti' code." [CNET]

"Microsoft is really the only company that spans the continuum, from the simplest Web client through he smartest client," said Fitzgerald. [Microsoft Watch]

"We just needed the clever name" – like Ajax, Fitzgerald said, to explain the various things that developers have been able to do for almost a decade with Microsoft technologies. [Microsoft Watch]

Using Atlas, developers will be able to write Ajax apps that contain pre-written code to smooth over technical distinctions between Web browsers, and debug those apps with Microsoft-branded tools, says Charles Fitzgerald, a general manager at Microsoft. Using Ajax today, he says, "is a little bit of a hack." [Information Week]

Here is what I think:

Microsoft invented the technologies now called AJAX, but moved away from browser based clients in favor of Windows based clients (Smart, Rich, Thick, Fat or otherwise).
The world of web development is quickly moving toward AJAX-style development. Microsoft is late and needs to make some mindshare.
Microsoft is a development tool vendor. They sell tools to make development easier, therefore, current AJAX development must be hard (rocket scientists need only apply) and messy.

Seems to me that many AJAX toolkits already exist. Many web applications are incorporating AJAX very quickly. Examples of AJAX range from simple enhancements to full blown applications, implemented by mere mortals.

This move does not seem in sync with Microsoft's .NET/WebForms/Smart Client agenda. Therefore, I question whether their heart is in the initiative. On the other hand, Microsoft's new RSS initiative (also connected to Fitzgerald) seems inline with current company agendas and has good backing inside and outside the company.

Update: Scott Isaacs of MSN Spaces and Scott Guthrie of ASP.NET have some good technical posts on AJAX.

In Search Of: A Usable UI

2005-06-27T23:56:00.000-04:00

Jeremy Zawodny's Surprising User Expectations post and Jeff Atwood's UI is Hard post draw attention to a big problem in software development: Developers rarely design good UI's. I have come to the conclusion that UI design should be handled by people who understand how users think, interact and model problems. This is more of a human factors problem than a coding problem.

I am a big proponent of making usable software. It's one of my crusades. Usability is not defined by developers, it is defined by users. We recently completed our second phase of usability testing on a new product. It's always a learning experience watching regular people trying to use software. It can be frustrating when it's software I helped to develop. To make better UI's, developers need to appreciate the obstacles that confront users and try remove the obstacles. Usability testing and reading people like Cooper, Nielsen and Norman can give you a better perspective.

Here are a couple guidelines I compiled from my own experiences and from people smarter than me:

Be flexible: Allow for multiple ways to get something done. Use main menus, toolbars, right-click menus, task panes and hyperlinks. This allows the user to choose the way most comfortable to them instead of forcing them to learn your way. Keep in mind that for any given user, the preferred method could change over time.
Be explicit: Don't force the user to guess or explore the UI. Use verbose captions, messages and explanations.
Be proactive: Don't wait until the user gets into trouble, keep the user from getting into trouble in the first place. Why wait until the end of a process to inform the user they made a mistake at the beginning?
Be forgiving: Make it possible for a user to recover from an unwanted action. People make wrong choices. Recovering from a bad choice with most of your data intact is far better than being forced to recreate something from scratch.
Be simple: Simple, focused screens and dialogs are easier to learn and allow users to get things done faster.
Be consistent: Make use of the fact the users can learn how to do things. Don't force them to re-learn how to do the same or similar things.

None of these points is revolutionary or even original. But it's amazing how few applications implement them.

Jeff's post has some good links to other articles that are worth checking out. He also brings up the concept of UI First development. I definitely agree that the UI should be given some focus early in the project. Unless your building an engine or library, the end-user is going to equate the UI with the software. If the UI is bad it won't matter how good the code is behind the scenes.

Update: For those interested, a co-woker pointed me to another UI First design methodology at Human Factors International (HFI).

MSHTML Hosting Article Published

2005-06-15T00:16:00.000-04:00

I wrote an MSHTML hosting article for the C++Builder Developer's Journal. They decided to make the issue freely available. HTML and PDF versions are available.

Rich UI vs User Experience

2005-06-14T22:41:00.000-04:00

John Montgomery and Jon Udell are having a discussion about AJAX and rich internet applications. Montgomery is trying to determine what all the fuss over AJAX is about. He played with some toolkits and is unimpressed. Why? He doesn't see how AJAX can compete with Winforms/Webforms on user experience. John says:

Mostly, Jon's posts got me to thinking about why we (that's you and me - Web users) are OK with degraded user experiences. I mean, for years we had great desktop applications to do things like calendaring and email and even mapping software. Then came the initial Web, where HTML 3.2 and some JavaScript meant that Web apps just couldn't be as nice as local apps. And now we're all very excited about things like Evite, Gmail, and Google maps. But compare Google Maps to Streets and Trips, which I did recently, and the experience with S&T is much better. Same with Outlook vs. Gmail (usually, anyway). Heck, most people read blogs through a Web browser, not an aggregator, even though aggregators are much more efficient. So why do we let ourselves settle?

I think he is confusing user experience for rich widgets. Web-based applications can achieve a high level of user experience and usability without the need for complex widgets. Good web applications are simple, small and well focused to the task at hand. In fact, I always use the web versions of the applications he lists over the desktop versions.

As John points out, the web-style hyperlink approach, with few options and everything laid out in front of the user, is easy to learn and use. To me, this increases user experience, not degrade it. John also points out that content is more plentiful in web-based applications and users like getting content. So much so that he feels users are willing to give up a great UI if they can get great content. Why does a user want a great UI at all? Seems to me that users only really care about content (or data). I think usability experts like Nielsen and Cooper would say a great UI is a UI that allows users to complete tasks without getting in the way. The UI should not be centerstage.

Udell's posts point out that AJAX systems have a tendency to allow users access to content they want in ways the web-UI did not anticipate. Also seeming to confirm my suspicion that users don't care much for flashy UI's, but graviate to applications that make it easy to extract and manipulate content. WebDAV and SOAP are not low-hurdle technologies, XmlHttpRequest seems to be. AJAX is a methodology for enhancing web application functionality, not for replicating desktop applications. People don't want desktop applications running in the browser, didn't Java teach us that?

XML File Formats in Office 12

2005-06-02T01:15:00.000-04:00

Brian Jones, program manager on the Word team posted news about the new XML file formats in Office 12. I have posted a few times on XML file formats, so I am interested in what Office is doing. Some interesting points:

Full fidelity. As good as the binary format.
Compressed. Lots of file parts stored in a structured ZIP archive, similar to OpenDocument
Fully documented. Whitepapers, documentation and XSD schemas.
Robust. A lot less likely to get a corrupt file that can't have pieces recovered.

IMO, the above points could be true for any product using an XML package format, but the fact that Office is doing it means millions of users can escape the data roach motel.

Scoble has more on Channel 9 as well as his own blog. Jones plans to link to whitepapers as soon as they become available on MSDN.

Granted, Office is following OpenDocument here, but this is a really good thing.

MSHTML Hosting - Drawing On WebBrowser

2005-04-24T00:42:00.000-04:00

Hosting the WebBrowser in your application makes it easy to create slick-looking textual UI's. HTML is a fairly expressive markup language and the results can be very professional with little difficulty. The graphical side is a little less impressive. Thankfully, SVG and VML (native support in the WebBrowser control) go a long way to fill the gap. Both have capabilities that blow away good old Win32 GDI drawing. Even so, there may be times that you wish you could grab an HDC for the WebBrowser control and start drawing on it. The WebBrowser control actually has a system built into it that allows you to do just that.

IHTMLPainter is part of a system in MSHTML called Binary Behaviors. Behaviors can do lots of cool stuff. Painters are a special kind of behavior called a rendering behavior. IHTMLPainter::Draw is called by MSHTML before or after the HTML content is rendered allowing you to draw below or above the content. MSHTML passes an HDC into method that you can use with any GDI or GDI+ drawing function. Basically, behaviors are COM objects that you implement and are associated with HTML elements, either in the HTML itself using CSS or progammatically using addBehavior. The MSDN has a nice tutorial on creating a rendering behavior that includes sample code.

XML Services In Desktop Applications

2005-04-24T00:27:00.000-04:00

It's pretty fair to say that I'd like to change the way I write desktop applications. I am tired of the UI framework lockin that comes with traditional desktop development. I've posted a couple times about using DHTML+SVG to create a desktop application UI. I have been working on prototypes in DHTML+SVG, as well as Laszlo (server-less deployment is now available) and Xamlon (they have a cool new flash-based system in addition to the .NET system).

I am now focusing my attention on non-UI parts of desktop applications and how Web-like techniques could be applied. Desktop applications, large ones specifically, are usually composed of subsystems that are exposed to the user via a host client. IMO, it's important to componentize these subsystems and get them to interact in a way that does not tightly couple them together. Sounds a lot like the definition of a Web service. One way of doing this in C++ is using abstract base classes as interfaces. I am beginning to find this method too object-oriented for my tastes. The sheer number of interfaces required to support the subsystem can be quite large. Interfaces usually cause a language lockin as well. C++ abstract base classes cannot be used very easily by other languages, unless your willing to completely wrap your interfaces with proxy code.

I am leaning more towards an XML services approach. Each subsystem would have a single entry point which would dispatch XML messages (in a RESTful sorta way) throughout the rest of the subsystem. This approach feels just like Web-based services and has the same kind of benefits. Just about any language can immediately start using the subsystem with minimal effort. The subsystem's dispatch entry point could be made HTTP-aware and suddenly gain the benefits of a true Web service:

Subsystems can be put on different machines.
HTTP techniques can be used to increase scalability and robustness.
Many different and special-use clients can be created which leverage the subsystem.

The kind of subsystems I am referring to include parsers, graph renders, expression evaluators, report generators, data converters and data analysis systems. These are examples of systems that should be made well-defined islands and have great potential for reuse. Instead, they are locked up into the UI client and can not be integrated into other solutions.

MSHTML Hosting - More Tricks

2005-04-02T16:31:00.000-05:00

Here are a couple miscellaneous tips for using the WebBrowser while in design (edit) mode.

Setting Focus In Design Mode

With the WebBrowser control in design mode, there are times that focus (and the blinking cursor) are not set correctly. For example, with focus in the editor, ALT+TAB away from your application, and then back again. Focus may not be set back into the editor. Here is a simple way to fix it. Put this code in an event or message handler that gets called when your application is re-activated:


IHTMLDocument2* pHTMLDoc2 = ...;
IHTMLWindow2* pWindow = 0;
pHtmlDoc2->get_parentWindow(&spWindow);
if (pWindow) {
  pWindow->focus();
  pWindow->Release();
}

Unselecting Current Selection

IHTMLTxtRange has a method to easily select a range of text, but there is no simple method to unselect an existing text selection. Here is a simple way to do it:


IHTMLDocument2* pHTMLDoc2 = ...;
IHTMLSelectionObject* pSelection = 0;
pHTMLDoc2->get_selection(&pSelection);
if (pSelection) {
  IDispatch* pDispRange = 0;
  pSelection->createRange(&pDispRange);

  IHTMLTxtRange* pTxtRange = 0;
  pDispRange->QueryInterface(IID_IHTMLTxtRange, (void**)&pTxtRange);
  if (pTxtRange) {
    VARIANT_BOOL bSuccess;
    pTxtRange->execCommand(CComBSTR(L"Unselect"), VARIANT_FALSE, CComVariant(), &bSuccess);
    pTxtRange->Release();
  }
  pDispRange->Release();
  pSelection->Release();
}

AJAX - Markets Abhor a Vacuum

2005-03-19T14:45:00.000-05:00

If you have only recently heard of greatness of AJAX, then you have not been paying attention for the last 5 years. Not that there's anything wrong with that. Lot's of people are quite excited by the new hype over HTML + JavaScript (+ XML + SVG), myself included. The reason for this post? Just to put down in words some of my reactions to things I've seen written in regard to the new hype.

CNET has an article discussing the renaissance and how AJAX may be used in the future, leading to a possible destruction of desktop applications. I love the media. Anyway, Charles Fitzgerald of Microsoft is quoted:

"It's a little depressing that developers are just now wrapping their heads around these things we shipped in the late 20th century,"

I can agree with that. None of this stuff is brand new. In the same article, David Mendels of Macromedia is quoted:

"It is really, really, really hard to build something like Gmail and Google Maps,"

"Google hired rocket scientists--they hired Adam Bosworth, who invented DHTML when he was at Microsoft. Most companies can't go and repeat what Google has done."

I think this is total crap. The article ends with a quote from David Temkin of Laszlo:

"The successors to Word and Excel and Powerpoint are not going to be written this way. It's just not going to happen."

This seems like a strange thing for a rich Internet application framework vendor like Laszlo to say. Even assuming that David was not quoted out of context, the statement is wrong.

Software products are mainly driven by markets. Users in those markets have needs and software is created to meet those needs. If your company makes a desktop OS, you'll probably make software that runs on the OS. At least until the users' needs change and the market forces you to re-evaluate how you build your software. How quickly you change the way you build your software depends on many factors, including the strength of the market forces and the cost of rewriting your existing codebase.

By the way, writing any kind of software application can be really, really, really hard. There is a difference between building a web-site and writing a web-application. And yes, I do have an aerospace engineering degree. Desktop or web, it's still hard.

My point is that if there was enough of a user need for presentation software that could be run from anywhere, the next version of PowerPoint would be built using an AJAX-like framework. It probably would not be Microsoft that builds it. They have an existing codebase that makes it costly to do such a thing. If PowerPoint was a product of the MSN division, things might be different. IMO, that group is doing some of the best new work at Microsoft.

John Gossman has a couple posts that also stirred me up. In general, John is definitely worth reading. He agrees with Temkin that Office will not be rewritten using AJAX, but attributes some of that to browser limitations. Many of those limitations are gone, including the advanced graphics issue he brings up. SVG and VML (in IE) do some pretty cool things. More than enough to drive a decent PowerPoint/Excel replacement.

Robert Scoble brings up offline usage in a recent post. Again, this limitation can be overcome. Since IE 5, web applications could use the userData behavior to store data locally. Together with client-side XML/XSLT, its pretty effective. I am sure Mozilla/Firefox has something similar.

The replacement does not need to have all the features of the desktop version. Successful web-based applications (like email, bug-tracking, ERP systems, RSS aggregators and blogging tools) have shown that users are willing to give up some of the "niceties" of a desktop version for the benefits of web-based deployment.

Markets (and users) abhor vacuums. If a web-based PowerPoint vacuum exists, some software vendor will fill it.

XML vs Serialization

2005-03-05T02:40:00.000-05:00

In this XML vs Serialization post, the author lists reasons why XML is not a good serialization format. I would turn the list around and say those are the exact reasons why XML is a good way to develop a serialization format. Even if its just an XML dump of your object model (I think we could do better than that), it's still better than a binary dump. If my object model changes, and it surely will, I can always transform the older XML dump to the newer structure. Even if its by a hand-written script. You can't easily do that with binary.

Also, I don't believe serialization implies the object model is more important than the data. I prefer to think it means the object model holds the data.

Via mnot

Object/Relational Mapping - No Thanks

2005-03-04T01:59:00.000-05:00

I have already posted some of my current feelings on using object hierarchies to hold state. It should come as no surprise then, that I am also questioning value of object-to-relational mapping systems. Why in the world would I want some system to create a multitude of objects just so I could manage state (not behavior) using those objects.

I still end up with a brittle object model that is difficult to navigate and breaks when my state changes and exposes the rest of my code to that breakage. SQL and XML both provide simple ways to query and navigate using loosely coupled techniques.

Fewer objects, not more. It does not matter if they are auto-generated or not. I still have to use them in my code.

Holding State as Objects is Painful

2005-03-03T01:43:00.000-05:00

As a developer, I write code. Code is good. I like code. But the people who use the applications I write could care less about the precious code. They care about.. wait for it... the data. Shocking, isn't it. I could have written the most elegant, wonderful code possible, but if I can't move their SuperApp version 1 files to SuperApp version 2, it's worthless.

Coding usually involves either holding state or executing behavior on the state. Holding state as an object hierarchy is really painful. First, someone has to write all those damn classes that map to the state. Then, changes to the state structure break the object model and any code using the object model. Besides brittleness, object models are a pain to walk (or navigate) and difficult to query or filter. Developers usually have to write other framework objects to support parent/child object relationships. Persisting from an object model can also be a pain and increases the likelihood of problems when the state structure (and therefore object model, and therefore persistence format) changes.

I say it's time to let it go. Focus on the data. Protect it. Ensure it's stored in a way that's robust enough to handle future changes. Think about this: MS Word 97 can open an MS Word 2003 file. Somebody was thinking about the data.

Use code to execute behavior on the data. Separate code from data, just like we're told to separate UI from business logic. If you've been reading my stuff, it should come as no surprise that I favor separating code from data by using XML to hold state. It's a means to an end. XML supports the kind of structure my state needs. It also supports standard ways to quickly walk or query for a piece of data from my state.

SVG & DHTML Applications

2005-02-06T17:10:00.000-05:00

I have been tinkering a lot lately with the concept of writing DHTML-based desktop applications running in a custom web browser. The custom browser would be made to look like the host shell of a standard Windows application with normal menus and toolbars. One of the pieces missing from DHTML applications in the past has been the lack of a graphics rendering system. Scalable Vector Graphics (SVG) fills this hole nicely. In fact, SVG will create graphics that rival any graphics library, desktop or otherwise. If you have not played with SVG, you owe it to yourself to have a look.

Besides static graphic rendering, SVG also builds on all the dynamic concepts in DHTML. SVG elements can have attached event handlers for mouse and keyboard events, among others. Javascript can be used to handle any of the events. SVG elements can also be animated very easily.

Currently, SVG is supported in MSHTML/WebBrowser via ActiveX viewers from Adobe and Corel. Mozilla/Firefox browsers will have native support sometime in 2005.

I think it is also worth mentioning the MSHTML/WebBrowser does support a native graphic markup language called Vector Markup Language (VML), which predates SVG and is very similar in design. If you want to natively support graphics (No ActiveX), you should consider VML.

MSHTML Hosting - Editing Tricks

2005-02-03T16:41:00.000-05:00

Show Table Borders

This is a little feature like you find in MS Word. It will display table invisible borders in light gray color so you can see the structure of the table even if borders are turned off. The feature only works when the WebBrowser is in design mode. Since it's an IOleCommandTarget editing command ID, it's quite simple to use:


IHTMLDocument2* pDoc = ...;

// Turn on editor mode
pDoc->put_designMode(CComBSTR(L"on"));

// Execute some commands
IOleCommandTarget* pCmdTarget = 0;
hr = pDoc->QueryInterface(IID_IOleCommandTarget, (void**)&pCmdTarget);
if (SUCCEEDED(hr)) {
  pCmdTarget->Exec(&CGID_MSHTML, IDM_SHOWZEROBORDERATDESIGNTIME,
                   OLECMDEXECOPT_DONTPROMPTUSER, CComVariant(true), NULL);
  pCmdTarget->Release();
}

Note the MSDN lists editing ID's separately from regular ID's.

Use DIV for Paragraph Breaks

Normally, when you press ENTER in design mode, WebBrowser will insert a paragraph tag, <P>, as a break. This can create large amounts whitespace between paragraphs since <P> tags are rendered with more padding than a simple line break. You can setup a CSS class or a style change the padding or you could tell WebBrowser to use <DIV> tags instead. There are two ways I know of to get WebBrowser to use <DIV> tags:

Use IDocHostUIHandler::GetHostInfo interface method. Look at the DOCHOSTUIFLAG_DIV_BLOCKDEFAULT flag.
Place an empty <DIV /> tag in the HTML you load into WebBrowser before putting it into design mode. Like this:
```
<HTML>
  <BODY>
    <DIV />
  </BODY>
</HTML>
```

MSHTML Hosting - More Editing

2005-01-29T16:00:00.000-05:00

Previously I talked about exposing the HTML editor hiding inside the WebBrowser control. I also talked about IOleCommandTarget and how you can control formatting and layout features of the editor. It won't take long before you discover that the IOleCommandTarget command ID's are somewhat limited. At some point, you will need to insert specialized text or HTML at the current cursor location or replacing the current selection. Luckily for us, there is an easy way to do it: IHTMLTxtRange.

I talked about IHTMLTxtRange in a previous post. It is useful for finding text or getting the text of the current selection. It can also do the reverse: It can insert text or HTML at the current cursor location or selection using the pasteHTML method. Here's a simple example:


IHTMLDocument2* pDoc = ...;

IHTMLSelectionObject* pSelection = 0;
HRESULT hr = pDoc->get_selection(&pSelection);
if (SUCCEEDED(hr)) {
   IDispatch* pDispRange = 0;
   hr = pSelection->createRange(&pDispRange);
   if (SUCCEEDED(hr)) {
      IHTMLTxtRange* pTextRange = 0;
      hr = pDispRange->QueryInterface(IID_IHTMLTxtRange, (void**)&pTextRange);
      if (SUCCEEDED(hr)) {
         CComBSTR sText = L"This is <b>better</b> text";
         pTextRange->get_pasteHTML(sText);
         pTextRange->Release();
      }
      pDispRange->Release();
   }
   pSelection->Release();
}

pDoc->Release();

In the above example, the selection may have selected text or it may just be a cursor location. The HTML overwrites any selected text. Otherwise, it's inserted at the cursor location.

Overall, IHTMLTxtRange is a very useful interface. I have used it for implementing spell check, find/replace and inserting complex HTML. Just to be clear, IHTMLTxtRange works when design mode is off or on. The WebBrowser control does not need to be in edit mode to call pasteHTML.

Hello JavaScript

2005-01-13T01:34:00.000-05:00

Coming from a C++ background, I found JavaScript very comfortable when I started doing DHTML programming. I was impressed with some of the things it could do with properties and functions. Other dynamic languages, Python and Ruby for example, have been getting lots of press lately while JavaScript has been quietly powering the Web.

That seems to be changing. I am reading a lot more about JavaScript. This is due in large part to Google's GMail and Suggest (how it works). These are great examples of what can be done with DHTML and created a lot of buzz. The JavaScript Weblog posted a summary of predictions that seem to be shared by others.

Go JavaScript!

MSHTML Hosting - User Content

2005-01-12T23:51:00.000-05:00

I have been posting about using MSHTML to display HTML-based content in your Windows applications. Some of the reasons I started doing this in my own code include:

Easy way to create a modern looking task-based UI.
Flexible and extensible, with a built-in script engine (JavaScript) and style system (CSS).
Based on open standards

There is another interesting by-product:

Very easy to allow end users to add their own custom HTML.

You're running a full-blown web browser inside your application. All you need to do is provide some way for the user to specify their own URL. It could be from within the application UI or maybe a special registry key. You pass the URL to Navigate and their custom content appears in your application. What a great way to open your application to your end users.

MSHTML Hosting - Calling JavaScript From Host

2004-12-21T01:09:00.000-05:00

I don't know how often someone would want to call a JavaScript (JS) function in the WebBrowser control from the host application. Since the host can control many, if not more, aspects of the HTML content externally using IDocHostUIHandler or the MSHTML DOM interfaces, it seems unnecessary to implement a method in JS and call that method from the host. But, if you need to for some reason, here's how to do it:


IHTMLDocument* pHTMLDoc = /* however you can get the IHTMLDocument */

DISPID idMethod = 0;
OLECHAR FAR* sMethod = L"DoSomething";
IDispatch* pScript = 0;
pHTMLDoc->get_Script(&pScript);
HRESULT hr = pScript->GetIDsOfNames(IID_NULL, &sMethod, 1, LOCALE_SYSTEM_DEFAULT,
                                    &idSave);
if (SUCCEEDED(hr)) {
  // invoke assuming no method parameters
  DISPPARAMS dpNoArgs = {NULL, NULL, 0, 0};
  hr = pScript->Invoke(idSave, IID_NULL, LOCALE_SYSTEM_DEFAULT, DISPATCH_METHOD,
                       &dpNoArgs, NULL, NULL, NULL);
}
pScript->Release();
pHTMLDoc->Release();

Notice we are using the IHTMLDocument interface, not the more often used IHTMLDocument2 interface. Also note that I am assuming no arguments are passed to the JS method. Check out IDispatch::Invoke for more information on calling a method with arguments. CodeProject has a few nice articles as well.

DHTML-Based Desktop Applications

2004-12-13T16:52:00.000-05:00

Recently, I've had several discussions with other developers about UI frameworks. One of the more interesting outcomes is my new desire to create desktop applications using traditionally web-based frameworks. I know it sounds weird, but after looking at the current UI framework landscape and factoring in the latest directions in rich Internet applications, it may not be too crazy. People like Jon Udell and Adam Bosworth have spent considerable time discussing the subject. Currently, there are several possible UI frameworks to choose from for commercial, shrink-wrapped applications (it's what I do):

MFC (Win32) - This popular framework should be avoided for new development. It's a dinosaur and will drag your application back into the stone age. It's quickly losing its leading edge status.
WTL (Win32) - This framework makes good use of modern C++ techniques, but it's in somewhat of a niche. Again, I don't think it should be used for new development.
VCL (Win32/NET) - I have always liked using this framework. It's really a predecessor to WinForms and .NET libraries. Ease of use and UI productivity is definitely high. There's even a nice migration to .NET from Win32. Borland's commitment is the biggest problem with this framework.
WinForms (NET) - The newest framework on block. Same RAD benefits of VCL, without the Borland problem. Well, not exactly. Microsoft is likely to moth-ball this framework before it really has a chance to succeed.
Avalon (NET) - The "on-deck" framework, not exactly ready for prime time. You can bet Microsoft will throw a lot of developer support at the framework, but when will it be production ready? And why only run on WinXP and greater? Win2K will still be active for a while and in numbers that commercial applications won't be able to ignore. Perhaps the security benefits of WinXP will cause migration to occur faster.
Rich Internet Apps (DHTML / FLEX / Laszlo / XUL) - Not really a framework, but a new category altogether. These kinds of applications are generally browser-based and are really starting to generate a lot of interest. Providing rich applications through a browser results in a better user experience than traditional webpage applications. In addition, these applications are built on frameworks that are also enterprise-ready, with regard to deployment and scalability. However, there appears to be no traction in the desktop application area.

Overall, the UI framework landscape is in the worst shape I have seen in years. As bad as I feel about MFC, at least there was a time where it was ubiquitous, leading-edge and strongly supported. Those days are gone and no other framework has stepped up yet (in reality, not hype). WinForms is probably the safest way to go for now for the following reasons:

It exists right now. Version 2 will be delivered in 2005.
It is currently built on Win32 API and support for Win32 API will not go away quickly.

Something else I think about is risk. The UI frameworks listed above all have some form of vendor lock-in or platform lock-in. I don't feel DHTML has lock-in. I am free to use various implementations on various platforms. It seems like less of a risk when I am not dependent on another company's UI framework. Hey, I try to separate business logic/data from UI code as much as I can, but that only helps mitigate the risk. The risk is still there, the cost of swapping UI frameworks is just smaller. Even XUL and FLEX have lock-in. Laszlo seems to have a plan for using Flash and .NET runtimes, which is a good thing.

What I am thinking about is creating a bare-bones DHTML desktop application runtime using MSHTML (for starters). Much of the needed functionality is already there. I have already posted a couple entries on using MSHTML to augment your Win32 or .NET application. The big difference now is that MSHTML would actual host your application. Think of it as a specialized web browser. Instead of browsing web pages, the primary function would be hosting DHTML applications. Whatever functionality is not already present could be added (generically) using MSHTML extension interfaces.

If rich Internet applications like Oddpost can be built, surely kick-ass desktop applications are possible as well.

OOD - Less Is More

2004-11-28T01:28:00.000-05:00

My primary professional development language has been C++ for as long as I remember. It still is and I have no strong desire to move to something else. That also means that, many years ago, I embraced the Object Oriented Design (OOD) methodology.

I have derived Cat and Dog from Animal many times. At first, it took a while to see the object hierarchies, but it became easier. I loved object hierarchies. The deeper, the better.

Then, I started COM programming and designing using interfaces (abstract base classes) seemed to free my mind of the implementation details. I was happy. I was using interfaces for non-COM code in no time.

Then, I started using templates. First, with the help of the STL. What a concept! Later, with the help of Modern C++ Design (Andrei Alexandrescu) and the Boost libraries. Implementing design patterns using templates was amazing. Templates allowed me to do things I thought only inheritance could. I am glad I was wrong. Suddenly, my object hierarchies are not as deep.

Then, I started to learn XML and Services. Not really programming, I know, but the concept of storing all that data in a document that could be queried so easily made me question all those class getters and setters. Even some kinds of inheritance seemed overkill. Why can't classes be more behavorial and less stateful? Let XML be the state and just pass it around.

In the end, I'm still using objects. Just less of them. I guess the data is becoming more important than the code.

MSHTML Hosting - Editing

2004-10-02T11:14:00.000-04:00

Did you know that you can turn WebBrowser into a decent WYSIWYG HTML editor? It's true and it's relatively simple. There are actually two ways to turn on the editor mode: contentEditable markup attribute, and IHTMLDocument2::designMode method. Since we are talking about embedding WebBrowser in an application, the IHTMLDocument2::designMode method is the most typical choice.

The basic steps are:

At this point you should be able to type, select, cut, copy and paste into the WebBrowser. But more than that, the editor allows you to quickly add various kinds of HTML formatting markup, such as: Font (Name, Size and Style), Colors, Horizontal lines, Paragraph and line breaks, Justification, and Indenting. It does this through a nice little interface called IOleCommandTarget. The interface has only two methods: QueryStatus and Exec. The interface can be used with many different OLE servers, such as Microsoft Word and Excel, but it is especially useful with WebBrowser.

Using IOleCommandTarget

At the heart of IOleCommandTarget is command identifiers. All commands supported by an implementer of IOleCommandTarget must have an identifier. Here is a list of MSHTML commands. Getting an instance of IOleCommandTarget is pretty simple: QueryInterface IHTMLDocument2 for it.


IHTMLDocument2* pDoc = ...;

// Turn on editor mode
pDoc->put_designMode(CComBSTR(L"on"));

// Execute some commands
IOleCommandTarget* pCmdTarget = 0;
hr = pDoc->QueryInterface(IID_IOleCommandTarget, (void**)&pCmdTarget);
if (SUCCEEDED(hr)) {
  // do commands here
  // ...
  pCmdTarget->Release();
}

QueryStatus provides a way to get the current state of a command. It is of limited value for most commands. Most uses include retreiving the current value of formatting commands. So, if you want to know if a command is supported, QueryStatus does the job. In addition, QueryStatus can be used to determine whether some toggle-type commands, such as IDM_BOLD, are "on" or "off". The following code checks to see if various Edit menu items should be enabled based on the current selection or clipboard contents:


OLECMD Cmnds[5];
::ZeroMemory(Cmnds, sizeof(OLECMD)*5);
Cmnds[0].cmdID = IDM_COPY;
Cmnds[1].cmdID = IDM_PASTE;
Cmnds[2].cmdID = IDM_CUT;
Cmnds[3].cmdID = IDM_DELETE;
Cmnds[4].cmdID = IDM_SELECTALL;

if (SUCCEEDED(pCmdTarget->QueryStatus(&CGID_MSHTML, 5, Cmnds, NULL)))
{
  bool bCanCopy = Cmnds[0].cmdf & OLECMDF_ENABLED;
  bool bCanPaste = Cmnds[1].cmdf & OLECMDF_ENABLED;
  bool bCanCut = Cmnds[2].cmdf & OLECMDF_ENABLED;
  bool bCanDelete = Cmnds[3].cmdf & OLECMDF_ENABLED;
  bool bCanSelectAll = Cmnds[4].cmdf & OLECMDF_ENABLED;
}

Exec is pretty simple. It provides the way to change the current value, insert a new item or perform an action. Exec allows commands to pass extra information or retrieve information via two VARIANT parameters. Some examples:


// Set current selection to bold
pCmdTarget->Exec(&CGID_MSHTML, IDM_BOLD,
                 OLECMDEXECOPT_DONTPROMPTUSER, NULL, NULL);

// Set current selection to tahoma
pCmdTarget->Exec(&CGID_MSHTML, IDM_FONTNAME,
                 OLECMDEXECOPT_DONTPROMPTUSER, CComVariant("Tahoma"), NULL);

// Set current selection to font size 2 (HTML font sizes, not points)
pCmdTarget->Exec(&CGID_MSHTML, IDM_FONTSIZE,
                 OLECMDEXECOPT_DONTPROMPTUSER, CComVariant(2), NULL);

// Copy current selection to clipboard
pCmdTarget->Exec(&CGID_MSHTML, IDM_COPY,
                 OLECMDEXECOPT_DONTPROMPTUSER, NULL, NULL);

MSHTML Hosting - IDocHostUIHandler

2004-10-02T11:11:00.000-04:00

We can't discuss embedding WebBrowser in an application without also discussing IDocHostUIHandler. The IDocHostUIHandler (and IDocHostShowUI) interface is the standard method provided by Microsoft for customizing how WebBrowser works when hosted in an application. Some of the things you can use IDocHostUIHandler to do include:

Disable standard right-click, context menu (or provide your own version)
Turn off the 3D border and scrollbars
Give the WebBrowser scripting engine access to your special purpose COM methods
Handle accelerator keys and URL's before MSHTML gets them

IDocHostUIHandler is an interface that you need to implement. How you implement depends on your development language and environment. For most languages, it means deriving a class from IDocHostUIHandler, adding code to the methods you want and returning safe, default values from those you do not want.

The next step is giving MSHTML your implementation of IDocHostUIHandler. Again, this depends on your development language and environment. The easy way is the "ICustomDoc" method. The best way is the "IOleClientSite" method. There is a nice C# article on CodeProject that discusses both methods (as well as some other good WebBrowser information).

ICustomDoc

This method requires only IDocHostUIHandler to be implemented which keeps things simpler. However, you have to give the interface to MSHTML after each page is loaded. The best way to do it is in the OnDocumentComplete or OnNavigationComplete events. This is the method I currently use in my applications. Code looks something like this:


IHTMLDocument2* pDoc = ...;
ICustomDoc* pCustom = 0;
hr = pDoc->QueryInterface(IID_ICustomDoc, (void**)&pCustom);
if (SUCCEEDED(hr)) {
  pCustom->SetUIHandler(pMyDocHostUIHandler);
  pCustom->Release();
}

IOleClientSite

This method requires that you implement IOleClientSite, as well as IDocHostUIHandler. The benefit is that you only need to give the interfaces to MSHTML once, before any HTML is loaded. I have not used this method in my applications, so I have no code to show you. I am planning on using it soon. I'll update this post when I am finished.

I am switching from ICustomDoc to IOleClientSite mainly because of a transient problem. When the WebBrowser control loads my custom HTML, it waits until it is completely loaded before getting my IDocHostUIHandler, so there is a split second where the borders and scrollbars are not displaying correctly. With IOleClientSite, WebBrowser asks for my IDocHostUIHandler before it loads the HTML.

MSHTML Hosting - Odds & Ends

2004-09-08T20:28:00.000-04:00

In this post I wanted to cover some miscellaneous things you may want to do with your embedded WebBrowser. On its own, the IWebBrowser2 interface does not support doing much more than we already covered in previous posts. However, if you start using the MSHTML DOM interfaces, much more functionality is available. Here is a list of simple things you can implement without too much difficulty:

Retrieving HTML from the WebBrowser.
Retrieving the HTML of the current selection.
Finding text in the HTML and selecting it.
Creating an image of the current HTML.

Retrieving HTML from the WebBrowser

There are times when you might want to get the currently loaded HTML from the control. You may want to save it to a file or parse it for information. For this functionality, you have to use the IPersistXxx interfaces. These are the same we used to load HTML into the WebBrowser from memory. The same works in reverse:


IHTMLDocument2* pDoc = ...;
IStream* pMyStream = ...;

IPersistStreamInit* pPersist = 0;
HRESULT hr = pDoc->QueryInterface(IID_IPersistStreamInit, (void**)&pPersist);
if (SUCCEEDED(hr) && pPersist) {
    hr = pPersist->Save(pMyStream, true);
    pPersist->Release();
}

Retrieving the HTML of the current selection

If you want to limit the HTML to just what a user has selected, instead of the entire document, we can use the IHTMLXxx COM interfaces. The first thing you need to do is get access to the IHTMLDocument interface for the current document. IWebBrowser2 gives you access using it's Document property. The Document property returns an IDispatch interface, so we need to QueryInterface the IDispatch interface for an IHTMLDocument interface, like so (raw C++):


IDispatch* pDocDisp = 0;
HRESULT hr = pWebBrowser->get_Document(&pDocDisp);

IHTMLDocument2* pDoc = 0;
hr = pDocDisp->QueryInterface(IID_IHTMLDocument2, (void**)&pDoc);
if (SUCCEEDED(hr)) {

    //...

    pDoc->Release();
}

pDocDisp->Release();

The IHTMLXxx interfaces follow the W3C DOM specification used for JavaScript very closely. If your familiar with those objects, the IHTMLXxx interface will be easy to grasp. In fact, if you know how to do something using JavaScript, you can duplicate it your compiled code using the IHTMLXxx interfaces.

That said, you can get the current selection as a IHTMLTxtRange from the document element. Once you have a text range, you can retrieve the plain text or HTML text as shown below:


IHTMLDocument2* pDoc = ...;

IHTMLSelectionObject* pSelection = 0;
HRESULT hr = pDoc->get_selection(&pSelection);
if (SUCCEEDED(hr)) {
   IDispatch* pDispRange = 0;
   hr = pSelection->createRange(&pDispRange);
   if (SUCCEEDED(hr)) {
      IHTMLTxtRange* pTextRange = 0;
      hr = pDispRange->QueryInterface(IID_IHTMLTxtRange, (void**)&pTextRange);
      if (SUCCEEDED(hr)) {
         CComBSTR sText;
         pTextRange->get_text(&sText);
         // or
         pTextRange->get_htmlText(&sText);
         //...
         pTextRange->Release();
      }
      pDispRange->Release();
   }
   pSelection->Release();
}

pDoc->Release();

Finding text in the HTML and selecting it

The Google toolbar in IE does this to make it easy to spot keywords found in the page. We are using body and text range objects. This time we are making a IHTMLTxtRange object, not getting the current selection. IHTMLTxtRange has find and select methods that make this task easy. Be sure to check out the parameters for IHTMLTxtRange::findText as they can be used to modify how the text is searched:


IHTMLDocument2* pDoc = ...;
IHTMLElement* pBodyElem = 0;
HRESULT hr = pDoc->get_body(&pBodyElem);
if (SUCCEEDED(hr)) {
   IHTMLBodyElement* pBody = 0;
   hr = pBodyElem->QueryInterface(IID_IHTMLBodyElement, (void**)&pBody);
   if (SUCCEEDED(hr)) {
      IHTMLTxtRange* pTextRange = 0;
      hr = pBody->createTextRange(&pTextRange);
      if (SUCCEEDED(hr)) {
         CComBSTR sText = "findme";
         VARIANT_BOOL bSuccess;
         hr = pTextRange->findText(sText, 0, 0, &bSuccess);
         if (SUCCEEDED(hr) && bSuccess == VARIANT_TRUE)
            pTextRange->select();
         pTextRange->Release();
      }
      pBody->Release();
   }
   pBodyElem->Release();
}

pDoc->Release();

Creating an image of the current HTML

Turning the contents of the WebBrowser into an image is not as straight forward as you may expect. Looking at the IHTMLXxx interfaces does turn up an IHTMLElementRenderer interface. IHTMLElementRenderer contains:

IHTMLElementRender::DrawToDC(HDC hDC);

You can try to use this method, but I have found that it is not very reliable and reacts inconsistently depending on the type of HDC you give it. A more reliable method uses an older OLE method. IViewObject supports the ability to render to an HDC. The IWebBrowser2::Document property can be QueryInterfaced for IViewObject. Two things to note while using this method, (1) you will probably want to turn off the scrollbars and 3D border since they will show up in the image and (2) you will want to resize the WebBrowser to the size of the contained HTML if you want to capture the entire content in the image. You may want to only make these changes temporarily and change them back after the image is captured:


IHTMLDocument2* pDoc = ...;
IHTMLElement* pBodyElem = 0;
HRESULT hr = pDoc->get_body(&pBodyElem);
if (SUCCEEDED(hr)) {
   IHTMLBodyElement* pBody = 0;
   hr = pBodyElem->QueryInterface(IID_IHTMLBodyElement, (void**)&pBody);
   if (SUCCEEDED(hr)) {
      // hide 3D border
      IHTMLStyle* pStyle;
      hr = pBodyElem->get_style(&pStyle);
      if (SUCCEEDED(hr)) {
         pStyle->put_borderStyle(CComBSTR("none"));
         pStyle->Release();
      }

      // hide scrollbars
      pBodyElement->put_scroll(CComBSTR("no"));

      // resize the browser component to the size of the HTML content
      IHTMLElement2* pBodyElement2;
      hr = Body->QueryInterface(IID_IHTMLElement2, (void**)&BodyElement2)
      if (SUCCEEDED(hr)) {
         long iScrollWidth = 0;
         pBodyElement2->get_scrollWidth(&iScrollWidth);

         long iScrollHeight = 0;
         pBodyElement2->get_scrollHeight(&iScrollHeight);

         // these lines depend on your WebBrowser wrapper
         pWebBrowser->SetWidth(iScrollWidth);
         pWebBrowser->SetHeight(iScrollHeight);

         pBodyElement2->Release();

         IViewObject* pViewObject;
         pDoc->QueryInterface(IID_IViewObject, (void**)&pViewObject);
         if (pViewObject) {
            /* however you want to make your image HDC.
               You can size it using iScrollHeight & iScrollWidth */
            HDC hImageDC = ... // could be bitmap or enhanced metafile
            HDC hScreenDC = ::GetDC(0);
            RECT rcSource = {0, 0, iScrollWidth, iScrollHeight};
            hr = pViewObject->Draw(DVASPECT_CONTENT, 1, NULL, NULL,
                                   hScreenDC, hImageDC, rcSource,
                                   NULL, NULL, 0);
            ::ReleaseDC(0, hScreenDC);
            pViewObject->Release();
         }
      }
      pBody->Release();
   }
   pBodyElem->Release();
}

pDoc->Release();

As you can see, there is a lot of things you can do using the MSHTML object model. Some of it can be tricky. Other things just aren't supported as well as they should be for an application developer. I guess you could say that application developers have their own list of issues for IE.

MSHTML Hosting - Mozilla

2004-09-06T06:00:00.000-04:00

Before moving ahead with the MSHTML hosting posts, I wanted to take a moment to talk about alternatives to WebBrowser. I am sure you are familiar with the Mozilla webbrowser. Started as an open source project by Netscape, Mozilla and its suite of companion projects are quite an achievement. One of the Mozilla projects is an ActiveX wrapper around the rendering engine which conforms to the IWebBrowser2 and DWebBrowserEvents2 COM interfaces. Created and maintained by Adam Lock the project has come along way. There is even minimal support for the IHTMLDocument DOM interfaces.

Everything we have covered in previous posts regarding WebBrowser functionality can be implemented using the Mozilla control as well. With no code changes! Just embed the Mozilla control and your application will not be dependent on Microsoft. Some of us like having choices.

My biggest problem with the Mozilla control is that the project is not moving fast enough to implement more functionality. Honestly, if Mozilla wants to grab more market share, it should be putting more resources on the project. One or two guys is not enough. I know that some people would tell me to just use the native Mozilla C++ classes and interfaces to embed the rendering engine. I am sorry, but there is too much to learn. A very large number of people know, and are comfortable using, ActiveX controls and COM data types. Frameworks have been built to make it easy to use such controls. Why would I want to learn a niche framework? That's the main reason I have not been able to contribute to the project myself. Its a large investment.

That said, I still love the idea of having choices. The Mozilla control is a great start and if I was writing an application that only need basic features, I would seriously consider using it. I hope very much that the project keeps progressing.

More...

Nick Bradury (author of FeedDemon and TopStyle) on Mozilla control.
Joel Spolsky (of Joel On Software) on why Mozilla should be actively building an ActiveX wrapper.

MSHTML Hosting - Building UI's

2004-09-03T06:00:00.000-04:00

My last posts have dealt with using the WebBrowser component to display HTML pages inside your application. We have seen how it does not take much to embed the control to create your own little mini-webbrowser. In this post I want to go a little further than building a webbrowser. Lots of applications are using a web-like UI. Applications like Intuit Quicken, Microsoft Outlook and Money actually use the WebBrowser control to achieve their web-like UI's. Microsoft Office task panes and other inductive UI's can be developed using the WebBrowser control.

When using the WebBrowser control for building a UI there are a few issues to consider:

Loading the HTML into the control. You most likely will not be using Navigate to load the HTML. In most cases you are dynamically generating the HTML from scratch or from a template loaded from a resource.
Handling mouse and keyboard events. Since you are building a UI, it is very likely that the content will be interactive. There may be edit boxes, push buttons and hyperlinks in the content. You will need to handle those events and respond accordingly.

Loading HTML

The most common (but not the only) way to load HTML from a buffer to the WebBrowser is via streams. Microsoft has a nice example in the WebBrowser reference. A quick Google search will turn up a way to do it in your favorite tool or language. The key points here are:

Navigate to "about:blank"
Wait for the blank document to finish loading
Load your HTML using the IPersistStreamInit method

Step #3 looks like this:


IHTMLDocument2* pDoc = ...;
IStream* pMyStream = ...;

IPersistStreamInit* pPersist = 0;
HRESULT hr = pDoc->QueryInterface(IID_IPersistStreamInit, (void**)&pPersist);
if (SUCCEEDED(hr) && pPersist) {
    hr = pPersist->InitNew();
    if (SUCCEEDED(hr)) {
        hr = pPersist->Load(pMyStream);
    }
    pPersist->Release();
}

Note: I would strongly recommend that any external links you have in your generated HTML (stylesheets or JavaScript) are referenced using absolute paths. Do not use relative paths. The IPersistStreamInit method does not update the control's base URL. Navigate does update the base URL. Therefore, any relative path will have "about:blank" prepended to it and the control will not likely find your external link.

Handling Events

The ability to handle mouse and keyboard events is critical when creating an interactive UI. There are 2 basic methods to do this with WebBrowser:

Use <A> tags to create hyperlinks with bogus href URL's. Then use OnBeforeNavigate2 to intercept the bogus URL, cancel the navigation and respond to the mouse click.
Hook your native code to the onclick, onkeypress, or any of the many other JavaScript events.

Method #1 is cheap and easy, but really only works with hyperlinks. In my applications, I create bogus hyperlinks that are easy to parse inside OnBeforeNavigate2 and contain breadcrumbs for me to use when responding to the click. Here is an example:

myapp://edititem/12345

I can look for a constant substring to indicate its my bogus HREF (myapp://). I can figure out the type of action (edititem). I also know which item to edit (12345). The last part could be a database ID or a pointer to an object cast to a long integer. The whole thing even looks like a real URL too.

Method #2 is much more robust, but a little more complicated to implement. There are more steps involved. You will also be working with the IHTMLDocument system and creating IDispatch wrappers. We'll cover those topics in future posts.

MSHTML Hosting - The Basics

2004-08-27T23:30:00.000-04:00

Hosting IE in your application is a relatively straight forward process, provided your development environment supports the use of ActiveX controls. Each language/framework has its own way of doing it: VB works directly with the WebBrowser control, MFC has its CHtmlView wrapper classes, Delphi has the TWebBrowser wrapper and C++Builder uses TCppWebBrowser. Create one of these somewhere in your application and your on your way to displaying HTML pages.

Before I go any further, I want to point you to the MSDN documentation of reusing the WebBrowser control. It will be an invaluable reference to you.

The WebBrowser control is really made up of a command interface (IWebBrowser2) and event interfaces (DWebBrowserEvents and DWebBrowserEvents2). Unless you are writing code against the raw control (please don't), your wrapper component will expose both of these sides to you automatically. The event names may be slightly different between components. Here are the most useful methods and events:

Document - This property is your means to gain access to the IHTMLDocument2 MSHTML interface. More on this in later posts, I just wanted to point it out now.
Navigate / Navigate2 - Provides a simple way to tell the WebBrowser to display a page from a given file or URL. Remember to specify the full URL (including http://). Navigate is the simpler method. Both support functionality such as passing in flags to keep the page from displaying in IE's cache list.
GoHome / GoBack / GoForward / Refresh - Allow you to mimic the IE functionality with the respective names.
ExecWB - Provides a way to get the WebBrowser to execute commands (listed here), such as Print, Print Preview, Save As, Copy and Find.
OnBeforeNavigate2 - Event that is called before the WebBrowser actually navigates to a given page. This event allows you to cancel or redirect the navigation. Many embedded browser applications use this event to implement "custom protocols" where clicking on a link will display your dialog, for example.
OnDocumentComplete - Event that is called when a page is fully loaded into the browser. Use this event as a trigger for hooking up other functionality that can only be done after a page is completely in the browser.
OnNavigateComplete2 - Event that is fired as individual pieces of the page are loaded. Many people assume this event will only be called once per page load. Not true, it is called once for each frame and then for the page. It is usually safer to use OnDocumentComplete, unless you need to be notified for each frame.

Using these methods and events, it is very easy to create a nicely featured web browser. Next time we can look at ways to make WebBrowser seem less like a web browser and more like a custom HTML display control you can use inside your application.

Working With MSHTML Hosting

2004-08-27T00:26:00.000-04:00

On the surface it seems like a great deal. You can actually embed MSHTML, the IE HTML rendering engine, in your own application. There is a lot of cool, simple features you get out-of-the-box. As soon as you get more advanced in your features, you find things are not so simple.

First, lets clear up some terminology:

WebBrowser - is an ActiveX control that you can embed in your applications to create a mini webbrowser. It will display HTML pages just as well as IE itself.
MSHTML - is a set of COM interfaces that you can use to programmatically access the elements of an HTML page. The interfaces also allow you to take part in Dynamic HTML events as well as behind the scenes operations like editing, custom rendering and behaviors, and selection.

WebBrowser depends on MSHTML. In fact there is not much beyond navigating to an HTML page that you can do with WebBrowser alone.

Myself and my team have become quite familiar with the ins and outs of MSHTML hosting. Never have I seen a more clear case of the 80/20 rule. MSHTML will get you 80% of your features very quickly and with relative ease. That last 20% will break most of you.

By no means do I consider myself an expert on MSHTML hosting, but I have implemented some tough features. One of the hardest things about moving past the beginner level stuff is the lack of real examples. I thought I would collect some links to stuff I found useful and post some code examples as well.

More to come

Mini-Milestones Can't Slip

2004-08-18T01:34:00.000-04:00

I am a big proponent of the staged delivery concept of software development. McConnell's treatment really brought it home for me when I first read Software Survival Guide. The recent Agile methods also preach the same ideas. It's just good sense: Always have a buildable, releasable product.

The reason for this post is not to act as a cheerleader for staged delivery. It's to vent-off some steam. At work, we have created a system of mini-milestones we are using to implement staged delivery. The other day we decide to slip a mini-milestone! Feature-creep /scope-creep caused us to miss a milestone!

I lost it. These milestones aren't for creating releases (we are far from that). The milestones act as checkpoints during the development process. The fact that we slipped a mini-milestone tells me that our process needs to be examined. The fact that we slipped is a red flag to me. If we can't contain scope-creep now, at this early point in the process, there is no way we can contain it later.

More on Task-based UI's

2004-07-31T00:34:00.000-04:00

Microsoft published the first article of a two-part series on Inductive UI (IUI) design, their buzzword for Task-based UI. This one covers a couple things:

How IUI can help users get frequent tasks completed faster.
What is a frequent task.
How you can implement a IUI design using a .NET library.

If you have ever seen an IUI design (think Task Panes in MS Office 2003), you will almost immediately see Web-style similarities. The article discusses this, referring to Dialog-style versus Web-style UI's. The author does note that in many cases experienced users will prefer Dialog-style UI's over Web-style. While I can agree with the sentiment, it usually happens in cases where the Web-style UI is designed to perform a long, drawn out wizard process. In most cases, such Task Panes, Web-style UI's are just as unobtrusive and straight forward as the Dialog-style counterparts.

Since I am working on a Task Pane infrastructure for an application at work, I was also interested in the details of the Web-style navigation library used to build Task Panes in .NET applications. The library allows programmers to create pages, which appear to be frame-like surfaces you can drop controls onto. The library manages a stack of those pages. This is different than our approach, which uses the MSHTML web browser component to host a stack of HTML pages.

Update: Part 2 is available.

Getting Started With P2P

2004-07-10T23:09:00.000-04:00

I finally have a reason to try to implement P2P in a development project. I have used TCP sockets on several occasions and I have played around with UDP broadcasts as well. What I am trying to do with P2P needs to be more reliable than the UDP broadcasts.

The first thing I did was Google for "P2P framework library". Unfortunately, not many relevant hits came back. The most popular was the Java-based JXTA toolkit. I work in C++, so it does not help me. Microsoft has a Peer-to-Peer toolkit, but it requires WinXP SP1 with Advanced Networking. I need to support OS's older than that.

However, both toolkits appear to have exactly what I would in a P2P toolkit:

Discovery
Peer Groups
Messaging (including multicast)

Working in C++ on Win32 (Win9x/WinNT/Win2K/WinXP) keeps me from using these toolkits.

I would really like to use an existing toolkit to abstract the P2P implementation details. It's going to be hard enough to get my own data sharing protocol working on top of P2P.

Other toolkits I have looked at include HOWL (an implementation of Zeroconf/Rendezvous) and BEEP. HOWL seems to only enable discovery. BEEP seems to only provide the messaging. I might look into merging the two together. I am also looking into wrappers for Multicast over Winsock.

Update: I have decided to work with Multicast for now. In the end, I'll need to create some kind of message protocol at which point I'll look at the RFC for BEEP.

Selling The Dream

2004-06-11T23:53:00.000-04:00

It's bound to happen sooner or later. Every so often Scoble (Microsoft blogging wunderkind) posts something that makes me question his sensibilities. One of his latest posts stopped me dead in my tracks. The post was a reply to a Jon Udell post on UI technologies in Longhorn. I thought Udell's post asked questions any professional should be asking. Scoble tries to bring it into focus by saying:

Ahh, but Jon, the real play here is one of programmer productivity

Programmer productivity. As if every new technology/language introduced in the last few decades failed to deliver on that same promise. As if Longhorn and .NET are the productivity "tipping point." As if being fluent in multiple technologies/languages is a bad thing. As if being fluent in multiple technologies/languages will go away.

Robert, your overselling the reality. I will use .NET to create commercial, shrinkwrap and enterprise software someday. I am becoming fluent in .NET technologies. But you should take a break from the Kool-Aid (although I hear the grape flavor is hard to put down). I see an advantage in understanding multiple technologies/languages and being able to choose the best for a particular situation. If anything, .NET will make the technology soup developers work with worse, not better. Just like every other "productivity improvement" before it.

High on XML

2004-06-09T00:38:00.000-04:00

I have talked about our experimentation with XML as a file format. This is going very well. Since we started working with XML and its related technologies, other ideas started popping up. It's not like XML is some magic concept, but it does open your mind enough to see other opportunities. Like creating a centralized Web Service to act as a repository for projects. You don't need XML to do something like that, but since XML and Web Services go together, it's easier to visualize how a service like that could be built off of (or into) our persistence system.

I think it's because there are so many examples of XML being used for various things. Anytime you see XML being used for some purpose, you can ask yourself if your use of XML, whatever that may be, can be applied the way someone else uses XML. Another example could be syndication. RSS and Atom are XML-based syndication formats. Can I syndicate our file format? Maybe just modifications. I'll have to float that one internally...

Task-based UI Design

2004-06-08T23:12:00.000-04:00

Developing new products is great for trying new things. There is no legacy and lots of freedoms. One of our areas that is screaming for experimentation is the UI. UI models have been changing in recent years. Many products are taking more of a Web-look. If you start digging into the design reasons, you'll run across discussions of Task-based UI or Inductive UI. It's not hard to find examples, especially from Microsoft: Windows XP uses Task Panes and Web-isms in many parts of the Shell; Office XP also makes heavy use of Task Panes; Applications like Quicken and Money have very Web-like UI's.

According to Microsoft, Task-based UI's are suppose to address the following problems:

Users don't seem to construct an adequate mental model of the product.
Even many long-time users never master common procedures.
Users must work hard to figure out each feature or screen.

The solution provided by Task-based UI's is to provide simple, task oriented views that show the user what can be done now and what they can do next.

Obviously, slapping some Task Panes in your application doesn't magically make it easier to use. This method is focused on the User Experience, but I would go further and say it's User Assistance. As such, we are involving our Documentation team in establishing the design and guidelines for use in the application. In addition, this method also seems to play well with the teachings of Cooper and Raskin. We are looking forward to see the effects on overall usability.

RAD Test Scripting

2004-05-28T01:08:00.000-04:00

The other day, some developer coworkers and I were talking about ways to make it easier for our Test group to create and maintain test scripts. Test scripts are a very important piece of the software development puzzle. But test scripts don't find new defects. Test scripts are really good at finding breakage. That's why scripts are run on new builds as BVT's or release candidates as part of a larger regression suite. For me, few things are worse than uncontrolled breakage to keep a project from hitting deadlines.

To find new defects, you really can't beat good test cases and exploratory testing. We wanted to find ways to keep our Test group working on finding new defects, not struggling to maintain scripts. Our current test scripting tool is just what it claims to be: A scripting tool. The problem with scripting is that it's programming and programming brings a whole set of issues to the party. We'd like to hide those issues from most of the testers and only have a small team worry about them, if possible.

The genius idea we hit upon was a sort of RAD system for creating test scripts. Ah yes, well I did say we are developers. The general idea is to componentize the creation of scripts. Testers could piece together various script components to create test cases and suites. Of course, there would be a nice Windows application to allow testers to build their projects. We would save the project in an intermediate format and "compile" to native script that our scripting tool would execute.

We even found an additional benefit of the system: By maintaining our test suites in an intermediate format, we avoid script tool vendor lockin. When we switch to a new test scripting tool, we just need to write a new "compiler" to convert to the new script language. Vendor lockin is a real problem. How many commerical test scripting tools do you know use a common, portable language? It can make switching vendors very costly.

We are currently prototyping a system. I'll let you know how it goes.

Test Scripts == Source Code

2004-05-24T15:11:00.000-04:00

How is it that a software development company that understands the value and importance of the code their developers write doesn't place the same value on the code their testers write? Good development processes apply to tester too. Regression test scripts are the health indicator of the development process. Build Verification Tests (BVT) or Smoke Tests are very important and, typically, rely on code written by testers.

Some mistakes I have seen in the past include:

Not storing scripts in a source control system
Not using a common/shared framework to build scripts
Not spending time to design or review scripts
Not building robust scripts that can be maintained across development cycles or even within the current cycle

There is a benefit from using test scripts. There is a cost as well. Use the same good sense you apply to your development process in your testing process.

Defects Love New Code

2004-05-24T00:49:00.000-04:00

People who know more about software development processes than me, and write books on the subject, frequently talk about metrics like Defect Density (defects per thousand lines of code). Say your development team averages 10 D/KLOC. If you start working on the next version of a product with 1M LOC and eventually add 100K LOC, you could look into your crystal ball and expect 1K defects. Holy crap! Honestly, it could be worse. In my experience, adding code to a 1M line product is likely to break lots of the existing code as well.

What if you start a product completely from scratch and end up with 1M LOC? 10K defects could give the faint of heart a reason to jump out a window. How will you ever know when to ship your product? I have written enough code in various products for various companies to know that those people writing those books know what they're talking about. I have seen it work out just like they predicted it would. Bad things happen to new code. I have come to expect it.

Sometimes people, usually pointy-haired types, get really caught up in things like defect counts. It drives me nuts. Defects are a fact of life in software development. You need to document and prioritize the defects discovered in your products. When it gets close to ship time, look at a cost benefit analysis of each defect. Compare the cost to fix to the cost of leaving it in the product. At some point, you will have to ship your product. It will have defects in it. Knowing what they are is a Good Thing. Making sure the bad ones were fixed is a Good Thing.

Joel On Software has a good article on the cost of fixing defects. Steve McConnell also has some good articles about when a product is ready to ship. They apply some rational thinking and decision making, instead of simply the "fix all bugs!" or "zero defect!" mantra pointy-haired types like to spout.

Using XML As File Format

2004-05-23T22:00:00.000-04:00

In my last post, I talked about some persistence issues we are working through and how persisting to XML could make things easier for us. In this post, I want to talk about using XML as a file format. Assuming we switch to an XML based file format for our products, there are questions I have regarding the proper use of XML.

Looking around, I can see at least 2 different categories:

XML file is a dump of your in-memory state at the time of saving.
XML file is a system unto itself and should be designed as a standalone deliverable of the product.

If you read my last post, you could guess the system we built for persisting objects falls clearly in to category #1. If you were to view the resultant XML, I doubt you'd be overwhelmed by the beauty of its structure. The XML is not being used to its full potential. No namespaces, no XPointer or XInclude. Just a raw dump of state stored in XML elements, with very little use of attributes.

On the other hand, if you were to look at the XML created by an MS Office product you would find a decent looking XML document. Namespaces are used and the XML elements don't appear to map directly to the product's underlying object model.

Want a better example? Look at a document file created using OpenOffice. These guys really cared about the XML file structure and use many XML standards (spec). In fact, there isn't just a single XML file. They create a ZIP archive and place several XML files in the archive. They also include a manifest file to describe the other files contained in the archive. Whenever possible, they use or extend existing XML based specs to implement their format. Clearly not a direct mapping to their object models.

How important is the XML structure when using XML as a native file format? We could always suggest people use XSLT to change our XML to suit their needs. That sounds reasonable, right?

Persisting Can be Painful

2004-05-23T21:46:00.000-04:00

We are considering changing from an OLE Structured Storage based file format to an XML based file format our flagship product. OLE Structured Storage has served us well, but we are starting to hit walls, especially with versioning and backward/forward compatibility. Yes, forward compatibility!

The product, mainly C++, has objects that save and load their state using a storage system. The storage system is IStorage/IStream and all of the objects know it. That's a minor problem that can be fixed. The bigger problem is the fact that the object hierarchy defines the structure of the file stream. That means any change to the object hierarchy changes the structure of the file stream. Or, any significant change in the object model (version 1.0 to version 2.0) makes it very painful for v2.0 to read v1.0 files. Why the headache? Since each object is responsible for saving/loading is own piece, an object in v2.0 may need to remember what it looked like in v1.0. Even worse, what if an object in v1.0 no longer exists in v2.0? It can get pretty ugly.

A different product, still in development, uses a system that abstracts way the "how" of the persistent storage. The objects that make up the business logic can save and load their state using an abstract storage interface. It has implementations for persisting to binary streams, SQL databases and XML streams. Its not revolutionary, COM's IPersist has allowed developers to do this kind of thing for years. However, we find ourselves primarily using the XML storage more than the others. In fact, we use it for more than persisting to files. We use it for copying state to clipboard and maintaining our Undo/Redo system as well. But I am getting ahead of myself.

I was reading a post by Chris Pratley where he talks about Word, RTF and XML:

RTF is used for this purpose instead since it is easier to deal with than Word binary for apps other than Word (remember that is why we created it - it stands for Rich Text interchange Format). The new XML format is designed for exactly that purpose - and it is easier to work with than RTF. You can create the WordML doc (or even a minimal subset) on a server using XML tools, then send the XML to Word on the client and Word will load it up. If you're missing a lot of the Word specific stuff, that's OK - Word will fill in the missing bits with defaults. In fact, you can skip generating the doc on the server if you want - just generate an XML data file in your own schema and provide an XSLT for Word to use when opening the file. That pushes a lot of the processing onto the client.

An idea for how to get past some of our versioning issues started to form:

What if our objects persisted to XML?
What if each version only cared about the structure of its XML?
What if we used XSLT or XQuery to convert one version's XML to another?

In my mind, forward compatibility (an old version opening a newer version's file) would be hard. Backward compatibility would be easier. Just transform the old XML to the current version's structure and load it. We could allow newer versions to save files in an older version's XML structure. That would be one way of handling forward compatibility. We are researching this concept to see where it can take us.