Quest for the perfect IM client

by Peter Tyrrell Thursday, February 21, 2008 10:24 AM

Some while ago, shortly after MSN/Windows Live Messenger stopped acting like an IM/chat client and more like a blinkity ad delivery platform*, I decided to look for an alternative. 


Trillian supports AIM, ICQ, MSN, Yahoo Messenger and IRC. It's small and fast and I used it for a year before it finally annoyed me for the last time by not remembering my window preferences. It also tended to lose my MSN password more often than I thought reasonable. Still better than MSN by a long chalk.


I just switched to Pidgin this week. It supports *many* (16) protocols including MSN, Yahoo, AIM, ICQ, GoogleTalk, and others I've never heard of, plus it has a fat pigeon icon, which counts for a lot. Pidgin runs on Windows and *nix, and there is a port for OS X. It's an open source project released under the GNU General Public License, and I like to support that kind of initiative. The interface is as fresh and clean as a Spring morning.


* Not just the ads. The following pile of of dung is from the Windows Live Messenger home page. Make a difference by getting advertised at? Uh... no.



A picture is worth 214748360.8 words

by Peter Tyrrell Wednesday, February 20, 2008 12:59 PM

Recently Ted put up an awesome Subsonic-powered auto-scaffold of a database so some quick and dirty entry could be done. Since each field has a maximum size, he shows the end user how many characters they have remaining, as they type. Nice!

So Bridget and I are going through the scaffold, testing it out, and we come across this Description field:


Hmm... only 1 billion characters remaining... give or take 73 million...

On a rough guesstimate of 5 characters per word on average, and 70 WPM typing speed, it would take someone, oh, 5.8 years of typing 24 hours a day, 7 days a week, with no holidays or bathroom breaks, to hit that limit.

Probably should change the field label to "FULL Description".


Another reason why validation matters.

by Ted Jardine Monday, February 18, 2008 2:34 PM

In a recent article by Chris Maunder of, he points out another essential reason to run a validator on your site: Google indexing. (Yes, you might notice that our out-of-date current Andornot site fails...a complete rewrite utilizing Umbraco is actually nearing the finish line - and it does validate). You can read more in the original article (in fact, please do so), but basically, setting the wrong DOCTYPE led to Google reporting the page as not found:

The problem we faced was that we had specified HTML 4.01 in our DOCTYPE but were trying to use XHTML style tags (i.e. self closing meta tags). IE had no problem with it. Firefox, Opera and even my blackberry had no problem with it (or if they did have a problem they were polite enough not to say anything). Yahoo didn't have a problem.

But Google did.

Google saw the DOCTYPE as being HTML 4.01. It then saw meta tags with a trailing "/>". It became scared and confused and decided that the only thing to do was report the page as not found.

Our custom error page had no meta tags so it was fine. Our article about templates had <> in the title which caused Googlebot enough confusion that it forgot about the self-closing meta tags and indexed the article.

We removed the "/"s from the meta tags and within 24hrs we were reindexed.

There were several other issues in addition to the above that they had to remedy as well, but again, to quote Chris:

W3C has HTML validators that we knew we failed but there was always a feeling of "so what?" The site rendered perfectly fine on the browsers we had access to. Why should this cause a problem?

As the Code Project found out first hand, paying attention to validation errors helps catch so many problems and potential pitfalls. It's not the be-all-and-end-all, but if you mistakenly think validation is just a theoretical exercise with no real-world implications, think again.

Tags: W3C

Google is your friend: "Cannot implicitly convert type 'string' to 'System.Web.UI.WebControls.TextBox'"

by Ted Jardine Monday, February 18, 2008 2:04 PM

Fortunately, I didn't waste too much time on this runtime error before googling and finding It turns out a compile time error is not thrown when there's a naming collision between ASP.NET 2.0's Page.Title property and a server-side control given the ID of "Title". Instead, the page in question will build no problem, but won't run. In my case I had given the ID of "Title" to one of a TON of new textboxes on a page I was working on in an ASP.NET 2.0 application.

Why this is able to make it past the compiler is beyond me.


A Webpublisher Xml class library and polymorphism

by Peter Tyrrell Thursday, February 14, 2008 4:26 PM

Last fall I wrote a new class library to handle Inmagic Webpublisher XML API calls with elegance and grace. That was the motivation anyway. One might well grasp the wind with chopsticks.

Each XML request type (query, insert, update, etc.) has some mandatory elements (e.g. textbase) and some optional elements (e.g. sort fields), so I used the Decorator Pattern to attach optional bits. The pattern provided the solution I was looking for, but threw me roughly into the world of OOP inheritance and polymorphism, where I felt at every turn like a man lost in a thorny thorn field without his pants.

I just found a way to remove a particularly sharp and prickly thorn.

The problem - Unable to access properties specific to a derived class

Consider this snippet of code:

// XmlInput is abstract base class, XmlQuery is derived from XmlInput
XmlInput query = new XmlQuery(tn, commandQuery, page, mr);
// Decorator wraps an XmlInput object
query = new SortFieldsDecorator(query, "Name|Product_Number".Split("|".ToCharArray()));

It's classic Decorator. The query object is at all times an XmlInput (the base class) type. You can pass it in to multiple decorators, and because it was instantiated as an XmlQuery, a class that derives from XmlInput, it gets some special XmlQuery-specific behaviour too (e.g. commandQuery, page, mr).

Trouble is, because the query object must be passed to decorators as XmlInput, there is no way to access the XmlQuery-specific public members:

// Cannot access XmlQuery-specific CommandQuery property! This doesn't work:
query.CommandQuery = "find blah =blah";

One consequence of this for me was that the derived classes such as XmlQuery had to jam every conceivable property into the constructor as a parameter, because they couldn't be set after the object was initialized. Not so bad with XmlQuery, as it happens, but a nightmare with XmlBatchModify which has many many properties:

// OMG!!! That's not even all of them!
public XmlBatchModify(string textbase, string password, ValidationType validation, BatchModifyActionType batchModifyAction, BatchModifyEntryType batchModifyEntry, bool matchCase, bool matchWholeWord)

Clearly something had to be done.

The fix? - Casting derived classes to base classes

I can go with the XmlQuery derived class from the get-go, set public properties after the constructor is called, and then cast the query object to the XmlInput base class before passing it to a decorator:

XmlQuery query = new XmlQuery(tn, commandQuery, page, mr);
// Now I can access XmlQuery-specific CommandQuery property
query.CommandQuery = "find blah =blah";
// Cast query object to XmlInput
XmlInput q = (XmlInput) query;
// Decorator accepts 
q = new SortFieldsDecorator(q, "Name|Product_Number".Split("|".ToCharArray()));

This works: properties specific to XmlQuery are not lost. I'm just not sure that it's entirely legal, or what consequences it may have in the long run.


Month List