This morning I got an email from an employee at StatCounter.com. She wanted to alert me to the presence of their stat counter on my website, pointing to another website that was an advertiser for Viagra. The StatCounter employee asked me:

Are you aware that there is a hidden link to a Viagra site on your site?

Ummm… no?

I was skeptical of the email, so I did a quick “view source” on my blog and sure enough the offending code was tucked away at the bottom on my HTML, right after my footer.

I spent a little bit of time trying to track down the hidden script, but with literally hundreds of potential candidate files to wade through in my Wordpress deployment, I opted for a quick Google search instead, and turned up this post from a fellow Wordpress user Aidan. The root of the problem is that apparently TemplateBrowser.com, where I got my theme from, is injecting themes with this additional, unwanted code.

This can be fixed very simply:

(1) Find the footer.php in the template directory and delete the call to the credit function.
(2) Find the functions.php file and delete the credit function.

That will eliminate the script.

Director Robert Zemeckis has a love affair. It is not with a woman. It is with the tracking shot.

There is a scene very early in Beowulf where the camera tracks backwards, away from King Hrothgar’s (Anthony Hopkins) Mead Hall, in one long, continuous shot. The camera slowly backs away from the hall, then the town, then flys over the land, beyond hills, through forests and caverns until it comes to rest upon the monster Grendel. It is a shot that is reminiscent of one that Zemeckis used in the film Contact, where he tracked the camera away from Earth, through the cosmos, beyond planets and stars for what seemed like several minutes.

Tracking shots are difficult to accomplish without special effects. Zemeckis clearly loves them, and this goes a long way toward explaining why Beowulf is 100% computer generated. Peter Jackson showed, with the Lord of the Rings, that these sorts of films could be made without CGI characters, but Zemeckis composes so many complex camera shots and uses so many long, uncut tracking shots that it becomes clear, very early in the film, that he could not have accomplished all of his goals using live action and real actors without an astronomical budget.

This begs the question: Was it worth it? Well, yes and no.

It is easy to admire what Zemeckis has accomplished with this film. There are moments when the camera is panning around, scanning back and forth, allowing us to see every meaningful moment of action with long, uncut sequences, and the overall effect is breathtaking. It is a feast for the eyes, and we immediately realize we’ve never seen camera work like this before. Zemeckis zooms us around, up and down, from sky to ground with such effortlessness that we feel a bit like a God, observing from on high, the events unfolding. It is a marvelous way to behold the retelling of a legendary story.

At the same time, we feel a bit cheated. When the camera has to fall on human flesh, it is clear that the characters are artificial, and they move with the same awkward stiffness as their cgi counterparts in Shrek. They lack the emotional range or weight of real actors, and that weakens the human element of the story. Of course, the lackluster writing and forgettable dialog don’t help matters much either.

But Zemeckis did not set out to create a tear-jerking, heart-pulling epic like Jackson’s The Lord of the Rings. Beowulf is all about spectacle. It is about translating a fantastic story into an equally fantastic film. And in that regard Zemeckis has succeeded. Beowulf is, above all other things, fun to watch. It is an explosion of imagery; a bounty of wonderful camera work and long, uncut scenes. It is the visual antidote to films like the Bourne Ultimatum.

One of the cool things about being a software developer is the chance to learn something new every day, even if it’s something small. I always get a little rush when I discover something I didn’t previously know.

The other day I was refactoring some code and ran up against an interesting bug. A WorkItem that I had created for a Use Case was responsible for creating several views in a DockWorkspace, and then exposing that view to another other WorkItem that wanted to create and use it, so that it could be shown in a WindowWorkspace, for example.

But a WindowWorkspace can be a tricky bugger; if the user clicks the Close button (”X”) in the upper right hand corner, the Form closes and disposes of the view.

Well… sometimes.

The WorkItem I created was wired-up to the view’s Disposing event to see when it was being disposed. Because when the view was disposed, the WorkItem was then in an invalid state - it’s fairly useless without the view - and in that case, I simply wanted the WorkItem to terminate, because it meant the user had clicked the “X” and closed that particular Use Case.

This WorkItem was used in two locations. In one location the WorkItem was created and it’s main view shown in a WindowWorkspace. When the user clicked the “X” button to close the Form, the WorkItem caught the Disposing event and Terminated correctly. The user could then re-open that WorkItem.

In another location, similar code (so it seemed) was doing the same job: creating the WorKItem and showing its view in a WindowWorkspace. But when the user clicked the “X” to close the Form, the view didn’t get Disposed and the WorkItem didn’t Terminate. When the user when to re-open that WorkItem the application would throw an exception because it already existed in the WorkItem collection hierarchy. This was unexpected.

I scratched my head for a few minutes trying to figure out why these two pieces of code that seemed to be using this WorkItem identically were functioning differently. It turned out that in one case, when the WorkItem’s view was shown, it was shown in the WindowWorkspace in a Modal fashion. In the other case, it was shown in a non-modal fashion. Both cases had very good reasons for showing them the way they did, so we couldn’t simply make them both the same. Plus, I wanted to know why I was seeing this behavior…

Upon further digging I found this on MSDN:

When a form is closed, it is disposed, releasing all resources associated with the form. If you cancel this event, the form remains opened.

That is the behavior I expected, and indeed verified with the first case. But then there’s this neat little note:

When a form is displayed as a modal dialog box, clicking the Close button (the button with an X at the upper-right corner of the form) causes the form to be hidden and the DialogResult property to be set to DialogResult.Cancel.

The Form is not Disposed…

Now, obviously this makes perfect sense. When you’re working with traditional Windows Forms you’re used to this behavior because you typically fetch a DialogResult back, and a Disposed object can’t send back a DialogResult. But when you get your mind attuned to the way CAB does things, sometimes, well, you forget :)

Intro to CAB

When Acropolis was announced, quite a few people I chatted with in e-mail and on message boards seemed to want to move away from CAB because they were afraid it would no longer be “maintained” or built upon. Fortunately, the SCSF Contrib Project has been busy steadily adding code and features to CAB. I haven’t had a chance to blog about much of the additions lately (or contribute myself, even though I have plans to add my UIService and WizardWorkspace to the code base), but I have taken notice of a few cool blog posts.

For starters, Rich Newman has put together a pretty darn nice looking Intro to CAB. It is one of the best point-by-point introductions to the CAB framework that I have seen (if a bit lengthy). Rich does a nice job of separating out some of the patterns and ideas (Command, Dependency Injection) from the way CAB implements them. So, if you’re new to the concepts as well as the framework (which many developers are) then you get to digest both the theory and the implementation as separate chunks, which I think is very valuable if you’re trying to learn this stuff for the first time. I highly recommend his site for people new to CAB.

ActionCatalog

The other really cool thing I saw in the last week or so is Bil Simser’s post on Taming the ActionCatalog in SCSF. The ActionCatalog has been a point of confusion for many developers. Here, though, Bil makes everything very clear with a concise explanation and some great code samples. It becomes really easy to see how one would go about utilizing this service to perform role-based UI configuration in a much less intrusive way.

I know for myself, I can’t wait to make use of what Bil outlines. In the application I’m currently working on, we have to do some role-based, permission-based UI configuration. But up to now, because of the limited amount of configuration we’ve had to do, we’ve done it the quick-and-dirty way. The ActionCatalog looks a lot better from where I stand.

So there’s some CAB updates to sink your teeth into.