Monthly Archives: November 2008

Happy V.I. Day!

A long overdue “Thanks!” to everyone who served over there (including my brother). Come home safe, guys!

Thanks (an early Thanksgiving Post)

It’s been a crazy week, fully of 3:00 am programming sessions, server restarts, tech calls, web sites in need of updates, and a dozen other things that go into preparing for the final holiday sales push at this little software company that’s been my home for the past 15 years. As if that weren’t enough, today was update day, which means I not only needed to push out the update for this week’s new comic indexing, but also handle as many as possible of of the content corrections and updates that have been flowing in all week.

My own desk is piled with work and half-finished projects, but with everyone else in the office busily  working on their own deadlines, I started tackling the queue that had grown by some seven hundred new submissions in just three days. “Man!” I thought. “Why do I do this job? I could have gone into writing medical software, but nooooooo…“. I was ready to bang my head against the desk out of sheer exasperation.

But then, in between editing the appearance notes, cover colorists, and countless other entries sent in by dozens of people from around the world in the past few days, I had one of those quintessential ComicBase moments where I was simultaneously stressed out by the workload, ferociously proud of what our little company has built over the past decade and a half, and utterly humbled by the amount of effort, care, and goodwill that causes relative strangers from half a world away to deluge us covers for a hundred issues of Martin Mystere, or hold raging forum battles over the proper way to denote character names in anthology storylines.

Like I said, sometimes I don’t know why I do this job. And I don’t know why so many other people are willing work so hard to help us. But man, am I glad you do!

I’m a big believer in work, and I respect the heck out of anyone, in any job, that gives it their all. On a personal level, I’m incredibly proud of what we’ve managed to with ComicBase and Atomic Avenue—projects that started with me wanting to find a way to catalog and sell my own comics, then got well and truly out of hand.

But as proud as I am of all that our little company has managed to do over the years, I still have to stand back occasionally and simply marvel at the sheer volume of effort that’s been donated by people I may never even meet, much less have the chance to buy a round of drinks for at San Diego. From helping moderate the discussion boards to correcting the spelling of “Sienkiewicz”, to driving the editors here collectively mad with your insistence that we start crediting cover inkers and colorists, you folks are the one who made ComicBase and Atomic Avenue what they are today. This isn’t some kind of false modesty on my part, it’s simply the truth.

Thank you. For everything.


Stopping “Invalid Callback or Postback” errors when using Ajax with dynamically filled dropdowns

This is one of those posts I’m just putting out there in the hopes it saves some other poor programmer the hours and hours worth of headaches that we just went through.

When we were developing the new search control panel for Atomic Avenue, we set it up so that several of the dropdownlists fill up with data based on other selections. For instance, if you choose to search by artist, a list of artist names will appear to choose from. As it turns out, such data-driven fields—particularly if they’re not always made visible until a later action (such as indicating you want to search by Artist) unhides them—is a great way to generate “invalid postback” errors under Ajax. This is especially true if you combine them with the AddHistoryPoint method in Asp.Net Futures’ July release to enable Back Button support.

The problem is that the new security controls in ASP.NET 2.0 can’t validate that the postbacks on the page were generated by those controls in the first place since (a) the contents can change as a result of the postback, and (b) the event validation may not have been set up in the first place if the control in question was hidden to start.

For the best rundown on the issue, here’s  the critical blog post by K.Scott Allen (check out part 1 as well)

Three options for getting around the situation presented themselves:

1. We could just disable the event validation checking, but that would open us up to new and fun injection attacks from folks faking postback data and using it to trick our web page into doing various inconvenient things.  In particular, we didn’t want to do that with our search since it was meant as a system-wide facility, meaning it would be used on virtually every page in the system.

2. We could avoid Ajax altogether and use traditional, full-page HTML rendering. This wasn’t a good option for us, since the Ajax-enabled version is *much* faster (and better looking) than the traditional HTML architecture which would require full page redraws after every control selection.

3. We could try calling Clientscript.RegisterForEventValidation and supply all the possible values of each dropdown prior to validation, but since there were often thousands of possibilities, this was impractical in the extreme.

So what was there to do? The answer was to roll our own version of the Dropdownlist control, leaving out the (non-inheritable) SupportsEventValidation attribute. By replacing the three problematic dropdownlists with the new control (“DynamicDropdownList”), we were able to get things working (including back button support) without tripping all over this rather thorny problem.


Code Sample


Amazing Bullet-Time Commercial

From Toshiba (courtesy of Gizmodo). Check out the “how it’s made” part as well!