Big changes are underway here.  First of all, our first child is now 18 months, and we’re expecting another boy in September.  My wife just graduated college.  I became SharePoint certified around the beginning of this year and have been working on several projects using that technology.

First is the subversion viewer that I’ve already posted about.  Then there’s an Exchange calendar viewer that I’m releasing as open source.  I also have another project in incubation that I may discuss later.  However, this is probably the last time I will mention those projects here.  I have rebuilt paradoxlost.com and will be doing most of my “professional” posting there.  Here I will post personal things, any writing that I do, and anything game related.

My Decal projects are currently suspended while I decide what i want to do with them.  They haven’t been rewarding for some time, but I don’t want to completely abandon them.  New code is randomly thrown into Decal, but nothing is polarizing the team to get a new release out.  Our primary server being down doesn’t help any either.  Perhaps Turbine’s recent acquisition by Warner Interactive will breath some life into AC.  If Decal picks up again, I will pick up my plugins again as well.

I ran across this for the first time, and thought it was worth putting together in one spot.  I was trying to deploy a solution into my test environment, which happened to have one web-front-end server offline.  Whether or not that was the cause I have no idea, but the solution decided to sit and wait.  After doing a bit of searching, I came across the canceldeployment command, but either due to bad luck or the net filter at work, I was unable to find out what the deployment id should be.  So I poked around a bit more and finally found the enumdeployments command.

Putting the pieces together you get:

stsadm –o enumdeployments

This will present some XML spew.  It’s easily readable, so find your solution name and get the job id. Then…

stsadm –o canceldeployment –id <id>

This will nuke the pending operation and put your solution into an error state.  You may then retract, delete, and try again.  This same process works for stuck retractions too.

Since he’s such a big boy, it took a little while longer, but he’s finally figured it out!

I’ve been a fan of SharePoint since WSSv2 first came out. Development on the platform wasn’t all that great though. Things changed in a big way with WSSv3, and had I known just how easy things had become, I would have started this project a long time ago.

After being introduced to Trac a few years ago, I immediately set up a site and linked it to my private repository. Having a wiki and source browser tied together can be immensely useful. The one thing I’ve always had an issue with regarding Trac is how it supports documents (barely at all). You can attach them to pages or put them in your repository, that’s it. SharePoint, however, was designed for document management; it just doesn’t have a way to browse a source repository. I decided to fix that.

After fetching SharpSvn I set about figuring out how to get it integrated with SharePoint. Eventually things came together, and I ended up with this:

That wasn’t enough though. I needed to be able to view those files too, and of course I wanted syntax highlighting. I don’t remember how I found this, but it works great. A bit more tinkering and…

Just need to do a bit of clean up and finish making the UI seamless with SharePoint.

So I’ve been motivated to work on Decal lately for some reason.  Maybe it was Virindi and Flynn talking about it; maybe I was just bored with my other projects.  I spent a few days on bugs here and there, hopefully fixing the vendor bug in adapter and another one with world iterators, and decide to test some of my own plugins.  Of course the biggest one is QuickBuff, since it’s the least simple, and of course it crashes horribly whenever I click start.  It seems somewhere along the line the ‘magic’ COM-thread marshaling quit working.  I’m not sure if it’s because of Vista or a recent .NET update, but either way, QB was dead.

I knew the issue was thread marshaling because the error was obvious:  COM Interface not found.  Of course I don’t want to debug this issue because I don’t really know how Mekle fixed it in the first place.  Instead I start converting everything to use the Invoke method that was already present in my framework to move all COM calls to the main thread.  After half a day of refactoring my task class everything looks good.  Until I get around to testing things.  It looks like my Invoke method isn’t working at all.

It turned out that I didn’t do enough research when I was looking up synchronization methods.  I had found and decided on the SynchronizationContext object, but the class doesn’t actually do anything.  Apparently it’s meant to be more of an example to implement a custom sync context.  After many, many false starts and even more crashes, I eventually went back to the good old Control.Invoke method.  I wanted to avoid this to keep from having a dependency on System.Windows.Forms, but aside from implementing my own sync context, I didn’t have much choice.

All said and done, this turned out to be a great batch of work.  The plugin is way faster and smoother than it was before and seemingly more stable too.  I even went ahead and implemented the adhoc/smart buffing feature, and I’m considering going forward with rebuilding the profile editor using the current view system.

I’ll do a release after I clean up the adhoc view some more, probably this weekend.

Words just cannot express…

So a dev buddy popped a question in IRC the other day.  He was trying to host an ad/offer thing inside of an iframe, but the offer checked for this and redirected the top page to itself.  He had been wracking his brain trying to work around this, and it looked like an interesting problem, so I stepped up to the plate.

First we attempted to simply overwrite location.replace with an empty function.  This seemed to work on IE but did nothing on FF3.  It also became apparent that this method would fail as a subsequent refresh gave us different javascript that simply changed the location.href.  FAIL.

I did a bit of googling on the issue and stumbled across a forum post suggesting the use of onBeforeUnload on the parent page.  I played around with this idea, getting mixed results, but since there seemed like no other way, I dug a bit deeper.  I was trying to do this by hand, with no libraries, and decided to bring in a little help since I didn't care to handle all the x-browser event nonsense.  I loaded up prototype.js and reworked my code to use it.  The following emerged:

function windowUnload(evt) {
var ifr = $('ifr');

if (ifr == evt.element()) {
evt.stop();
}
}

Event.observe(window, 'unload', windowUnload);
$('ifr').observe('unload', windowUnload);

The id 'ifr' is the iframe holding the offer/ad.  This also manages to prevent any unload checks that the embedded page might popup.

Enjoy!

He’s finally here!!  Well, I’m a slacker really, since he’s been here for 6 weeks now.

Enjoy a few pictures!

While we were in Florida we had been told to visit a restaurant called Boondocks.  They have some great burgers there and another really curious attraction:  Bread/Fry addicted fish...

Back at the beginning of August, we spent a week in Florida.  Below are some highlights.