May 12, 2004
Something exciting on sourceforge...

Guess what's here: http://sourceforge.net/projects/wtl/

That's cool. That's very cool.

Posted by Simon at 06:15 PM
March 25, 2004
Why are ATL and WTL Upside Down?

An excellent article from Jim Beveridge:

ATL and Upside-Down Inheritance explains the reasoning behind the slightly eccentric design choices made in the ATL windowing framework.

Posted by Simon at 08:11 PM
January 17, 2004
VS.NET Useful WTL Macros

Programmers Notepad 2 is developed using the Windows Template Library which is a library of code that makes working with Windows easier (amongst other things). WTL supports message maps which MFC users will also be aware of - basically a block of macros that direct incoming window messages to multiple handler functions. Working with message maps in WTL can be a bit of a bind as there is less good IDE support and I don't use the message-specific crackers in PN2. Therefore, I use a couple of macros to fill out notification, command and message handler prototypes for me:

Get: WTLMacros.vb which uses CleverStuff.vb to manage Undo state.

I hope someone else finds these macros useful. To try one out, simply type something like:

OnInitDialog

and then run the MessageHandler macro (if the code is not all in one file, run the MessageHandlerDefinition macro in the header, and the MessageHandler macro in the source file).

Posted by Simon at 03:59 PM
May 07, 2003
Simulated Dynamic Binding

I'm going to try and write a bit more about WTL in the future, and this is the first mini-article. Many people who use WTL ask why so many classes need to be defined like this:

class MyWindow : public CWindowImpl<MyWindow>
{
}

The base class then calls methods (possibly in your class) by doing this:

T* pT = static_cast<T*>(this);
pT->SomeFunction();

This effectively provides a compile-time virtual function. If I implement SomeFunction in my class then it will be called by this code. Otherwise, the code in the base-class will be called. Some of the reasons that this is beneficial over using virtual functions are:

  1. Two levels of runtime indirection saved (virtual function pointer + virtual function table).
  2. static_cast calculations can be performed at compile time - no runtime cost.
  3. Possibly saves on having any virtual function pointer and vtable - saving space (albeit minimal savings).
  4. The base class doesn't actually need to define the method - like a pure virtual function.
  5. You can call static methods and public members (both static and non-static).

There are a number of names for this technique, the common one (on the WTL list at least) seems to be "simulated dynamic binding".

According to Igor Tandetnik on the WTL list, the method is probably first mentioned in "Curiously Recurring Template Patterns", C++ Report, February 1995 by James O. Coplien. Apparently Coplien attributes the pattern to others. The pattern is reproduced in the book "C++ Gems".

I've put this mini-article together having read through the recent discussion on the WTL yahoo group. My particular thanks to Daniel Bowen, Igor Tandetnik and Tim Tabor for information that I've used in this post.

Posted by Simon at 11:34 PM
April 15, 2003
Pranish Kumar responds on the WTL list

Pranish responded to the discussion on the wtl discussion group caused by his previous message:

http://groups.yahoo.com/group/wtl/message/5487

Let's hope that all this leads to a good future for WTL, with some more open support from Microsoft.

Posted by Simon at 11:40 AM
April 14, 2003
The future of WTL

Interestingly, Pranish Kumar posted to the WTL discussion group on yahoo trying to gain opinions on how MS could best support the WTL developer community. You can find his message there, and I've copied my reply to him below:


> and the addition of knowledgeable support personnel to the Microsoft 
> official support channels.

I think it would be a great start for Microsoft to provide some form of officially sanctioned discussion forum. Yahoo groups is advertising supported, incredibly irritating to use (IMHO) and extremely unprofessional. I think microsoft could at least fund the provision of a mailing list / news group combination (with web archives) that would give people a little more confidence in believing that microsoft aren't ignoring WTL.

> There would also likely be significant 
> changes to the library itself as we moved it forward to the latest 
> version of ATL and the compiler. 

Hopefully this will happen - I'm sure nobody here wants to be unable to use WTL with the new ATL. If Nenad has managed before, surely it doesn't cost you _that much_ to do this.

> Related to this the team is investigating various ways that we can 
> improve the experience for WTL users without incurring the 
> prohibitive overhead. Some of the possibilities we are investigating 
> include modifying the licensing for WTL so that the WTL community 
> could support itself with a shared-source project.

Shared-source: please define.

Ignoring the precise definition of this term, some form of open development (a product able to live without Nenad - god forbid) could be important so that WTL can live on beyond the interest-span of one developer. However, a complete Open Source project could turn into a nightmare unless it is properly managed. Many open source projects suffer from the old "too many chefs spoil the broth" problem. A project like WTL could be especially succeptible to this because it is highly technical underneath the polished cover.

What would be ideal (it seems to me) would be some form of public project sponsored by microsoft - a web site explaining it, proper discussion groups and somewhere that community members can post examples etc. Contributions of source would be welcome from community members, but would have to be approved by a few key developers (preferably members of the MS ATL/MFC team). This retains some level of quality control, but doesn't suffer from the speed and cost problems of product-izing WTL.

Somebody else mentioned code documentation - I would like to add my voice to that plea. Some form of standardised code commenting mechanism that could be parsed with either Doxygen or NDoc or equivalent would be particularly helpful in providing better WTL documentation.

Just my two english pence,


Simon.

Posted by Simon at 02:21 PM